[lkml]   [2019]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] mm: Fix a huge pud insertion race during faulting
Hi, Dan,

On 10/16/19 3:44 AM, Dan Williams wrote:
> On Tue, Oct 15, 2019 at 3:06 AM Kirill A. Shutemov <> wrote:
>> On Tue, Oct 08, 2019 at 11:37:11AM +0200, Thomas Hellström (VMware) wrote:
>>> From: Thomas Hellstrom <>
>>> 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 <>
>>> Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
>>> Signed-off-by: Thomas Hellstrom <>
>>> ---
>>> 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?



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