lkml.org 
[lkml]   [2008]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] memcg: fix oops in oom handling
KAMEZAWA Hiroyuki wrote:
> On Mon, 14 Apr 2008 14:52:00 +0800
> Li Zefan <lizf@cn.fujitsu.com> wrote:
>> It's reproducable in a x86_64 box, but doesn't happen in x86_32.
>>
>> This is because tsk->sighand is not guarded by RCU, so we have to
>> hold tasklist_lock, just as what out_of_memory() does.
>>
>
> Good catch! and patch seems good.
>
> Paul, I have one confirmation. Lock hierarchy of
> cgroup_lock()
> -> read_lock(&tasklist_lock)
>
> is ok ? (I think this is ok.)
>

I think so, because we used to have this in cgroup:

mutex_lock(&cgroup_mutex);
-> attach_task_by_pid()
-> read_lock(&tasklist_lock)

But afte some time, some uses of tasklist_lock is replaced by rcu.

> Thanks,
> -Kame
>
>> Signed-off-by: Li Zefan <lizf@cn.fujitsu>
>> ---
>> mm/oom_kill.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index f255eda..beb592f 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -423,7 +423,7 @@ void mem_cgroup_out_of_memory(struct mem_cgroup *mem, gfp_t gfp_mask)
>> struct task_struct *p;
>>
>> cgroup_lock();
>> - rcu_read_lock();
>> + read_lock(&tasklist_lock);
>> retry:
>> p = select_bad_process(&points, mem);
>> if (PTR_ERR(p) == -1UL)
>> @@ -436,7 +436,7 @@ retry:
>> "Memory cgroup out of memory"))
>> goto retry;
>> out:
>> - rcu_read_unlock();
>> + read_unlock(&tasklist_lock);
>> cgroup_unlock();
>> }
>> #endif
>> -- 1.5.4.rc3
>>
>>
>>
>>
>


\
 
 \ /
  Last update: 2008-04-14 09:29    [W:0.048 / U:1.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site