lkml.org 
[lkml]   [2019]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] mm: Fix a huge pud insertion race during faulting
On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov <kirill@shutemov.name> wrote:
>
> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
> > From: Thomas Hellstrom <thellstrom@vmware.com>
> >
> > 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@infradead.org>
> > Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
> > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> > ---
> > 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.

\
 
 \ /
  Last update: 2019-10-16 03:45    [W:0.088 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site