Re: [RFC][PATCH] Clarify mem_cgroup lock handling and avoid races.

[Hugh Dickins <hugh@veritas.com>]

On Fri, 22 Feb 2008, Balbir Singh wrote:
> 
> I've been looking through the code time and again, looking for races. I will try

Well worth doing.

> and build a sketch of all the functions and dependencies tonight. One thing that
> struck me was that making page_get_page_cgroup() call lock_page_cgroup()
> internally might potentially fix a lot of racy call sites. I was thinking of
> splitting page_get_page_cgroup into __page_get_page_cgroup() <--> just get the
> pc without lock and page_get_page_cgroup(), that holds the lock and then returns pc.

I don't think that would help.  One of the problems with what's there
(before my patches) is how, for example, clear_page_cgroup takes the
lock itself - forcing you into dropping the lock before calling it
(you contemplate keeping an __ which doesn't take the lock, but then
I cannot see the point).

What's there after the patches looks fairly tidy and straightforward
to me, but emphasize "fairly".  (Often I think there's a race against
page->page_cgroup going NULL, but then realize that pc->page remains
stable and there's no such race.)

> 
> Of course, this is just a thought process. I am yet to write the code and look
> at the results.

I'd hoped to send out my series last night, but was unable to get
quite that far, sorry, and haven't tested the page migration paths yet.
The total is not unlike what I already showed, but plus Hirokazu-san's
patch and minus shmem's NULL page and minus my rearrangement of
mem_cgroup_charge_common.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>