Messages in this thread |  | | Date | Tue, 15 Mar 2011 08:42:57 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH] thp+memcg-numa: fix BUG at include/linux/mm.h:370! |
| |
On Mon, 14 Mar 2011 20:58:23 +0100 Johannes Weiner <jweiner@redhat.com> wrote:
> On Mon, Mar 14, 2011 at 06:17:31PM +0100, Andrea Arcangeli wrote: > > On Mon, Mar 14, 2011 at 09:56:10AM -0700, Linus Torvalds wrote: > > > Does mem_cgroup_newpage_charge() even _need_ the mmap_sem at all? And > > > if not, why not release the read-lock early? And even if it _does_ > > > need it, why not do > > [...] > > > About mem_cgroup_newpage_charge I think you're right it won't need the > > mmap_sem. Running it under it is sure safe. But if it's not needed we > > can move the up_read before the mem_cgroup_newpage_charge like you > > suggested. Johannes/Minchan could you confirm the mmap_sem isn't > > needed around mem_cgroup_newpage_charge? The mm and new_page are > > stable without the mmap_sem, only the vma goes away but the memcg > > shouldn't care. > > We don't care about the vma. It's all about assigning the physical > page to the memcg that mm->owner belongs to. > > It would be the first callsite not holding the mmap_sem, but that is > only because all existing sites are fault handlers that don't drop the > lock for other reasons. > > I am not aware of anything that would rely on the lock in there, or > would not deserve to break if it did. >
mmap_sem is not required to held if uncharge() operation is done if vma turns out to be a stale pointer.
Thanks, -Kame
|  |