Re: [RFC PATCH] mm: Fix a huge pud insertion race during faulting

[Thomas HellstrÃm (VMware)]

Hi, Dan,

On 10/16/19 3:44 AM, Dan Williams wrote:
> On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
> > On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas HellstrÃm (VMware) wrote:
> > > From: Thomas Hellstrom <thellstrom@xxxxxxxxxx>
> > >
> > > A huge pud page can theoretically be faulted in racing with pmd_alloc()
> > > in __handle_mm_fault(). That will lead to pmd_alloc() returning an
> > > invalid pmd pointer. Fix this by adding a pud_trans_unstable() function
> > > similar to pmd_trans_unstable() and check whether the pud is really stable
> > > before using the pmd pointer.
> > >
> > > Race:
> > > Thread 1:             Thread 2:                 Comment
> > > create_huge_pud()                               Fallback - not taken.
> > >                      create_huge_pud()         Taken.
> > > pmd_alloc()                                     Returns an invalid pointer.
> > >
> > > Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> > > Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
> > > Signed-off-by: Thomas Hellstrom <thellstrom@xxxxxxxxxx>
> > > ---
> > > RFC: We include pud_devmap() as an unstable PUD flag. Is this correct?
> > >       Do the same for pmds?
> > I *think* it is correct and we should do the same for PMD, but I may be
> > wrong.
> >
> > Dan, Matthew, could you comment on this?
> The _devmap() check in these paths near _trans_unstable() has always
> been about avoiding assumptions that the corresponding page might be
> page cache or anonymous which for dax it's neither and does not behave
> like a typical page.

The concern here is that _trans_huge() returns false for _devmap() 
pages, which means that also _trans_unstable() returns false.

Still, I figure someone could zap the entry at any time using madvise(), 
so AFAICT the entry is indeed unstable, and it's a bug not to include 
_devmap() in the _trans_unstable() functions?

Thanks,

Thomas