[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3182585.1217908165040.kamezawa.hiroyu@jp.fujitsu.com>
Date: Tue, 5 Aug 2008 12:49:25 +0900 (JST)
From: kamezawa.hiroyu@...fujitsu.com
To: balbir@...ux.vnet.ibm.com
Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Lee Schermerhorn <Lee.Schermerhorn@...com>,
MinChan Kim <minchan.kim@...il.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-mm <linux-mm@...ck.org>, Rik van Riel <riel@...hat.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Re: Race condition between putback_lru_page and mem_cgroup_move_list
>KOSAKI Motohiro wrote:
>> Hi
>>
>>>> I think this is a race condition if mem_cgroup_move_lists's comment isn't
right.
>>>> I am not sure that it was already known problem.
>>>>
>>>> mem_cgroup_move_lists assume the appropriate zone's lru lock is already h
eld.
>>>> but putback_lru_page calls mem_cgroup_move_lists without holding lru_lock
.
>>> Hmmm, the comment on mem_cgroup_move_lists() does say this. Although,
>>> reading thru' the code, I can't see why it requires this. But then it's
>>> Monday, here...
>>
>> I also think zone's lru lock is unnecessary.
>> So, I guess below "it" indicate lock_page_cgroup, not zone lru lock.
>>
>
>We need zone LRU lock, since the reclaim paths hold them. Not sure if I
>understand why you call zone's LRU lock unnecessary, could you elaborate plea
se?
>
I guess the comment should be against mem_cgroup_isolate_pages()...
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists