Messages in this thread | | | Subject | Re: [RFC PATCH] mm: Fix a huge pud insertion race during faulting | From | Thomas Hellström (VMware) <> | Date | Wed, 16 Oct 2019 07:59:15 +0200 |
| |
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@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.
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
| |