[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120720144041.GG12434@tiehlicka.suse.cz>
Date: Fri, 20 Jul 2012 16:40:42 +0200
From: Michal Hocko <mhocko@...e.cz>
To: Mel Gorman <mgorman@...e.de>
Cc: Linux-MM <linux-mm@...ck.org>, Hugh Dickins <hughd@...gle.com>,
David Gibson <david@...son.dropbear.id.au>,
Ken Chen <kenchen@...gle.com>,
Cong Wang <xiyou.wangcong@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: hugetlbfs: Close race during teardown of hugetlbfs
shared page tables V2 (resend)
On Fri 20-07-12 15:37:53, Mel Gorman wrote:
> On Fri, Jul 20, 2012 at 04:29:20PM +0200, Michal Hocko wrote:
> > > <SNIP>
> > >
> > > Signed-off-by: Mel Gorman <mgorman@...e.de>
> >
> > Yes this looks correct. mmap_sem will make sure that unmap_vmas and
> > free_pgtables are executed atomicaly wrt. huge_pmd_share so it doesn't
> > see non-NULL spte on the way out.
>
> Yes.
>
> > I am just wondering whether we need
> > the page_table_lock as well. It is not harmful but I guess we can drop
> > it because both exit_mmap and shmdt are not taking it and mmap_sem is
> > sufficient for them.
>
> While it is true that we don't *really* need page_table_lock here, we are
> still updating page tables and it's in line with the the ordinary locking
> rules. There are other cases in hugetlb.c where we do pte_same() checks even
> though we are protected from the related races by the instantiation_mutex.
>
> page_table_lock is actually a bit useless for shared page tables. If shared
> page tables were every to be a general thing then I think we'd have to
> revisit how PTE update locking is done but I doubt anyone wants to dive
> down that rat-hole.
>
> For now, I'm going to keep taking it even if strictly speaking it's not
> necessary.
Fair enough
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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