lkml.org 
[lkml]   [2020]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From
Date
On 9/10/20 3:11 PM, Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote:
>
>> Or am I way off here, and it really is possible (aside from the current
>> s390 situation) to observe something that "is no longer a page table"?
>
> Yes, that is the issue. Remember there is no locking for GUP
> fast. While a page table cannot be freed there is nothing preventing
> the page table entry from being concurrently modified.
>

OK, then we are saying the same thing after all, good.

> Without the stack variable it looks like this:
>
> pud_t pud = READ_ONCE(*pudp);
> if (!pud_present(pud))
> return
> pmd_offset(pudp, address);
>
> And pmd_offset() expands to
>
> return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address);
>
> Between the READ_ONCE(*pudp) and (*pud) inside pmd_offset() the value
> of *pud can change, eg to !pud_present.
>
> Then pud_page_vaddr(*pud) will crash. It is not use after free, it
> is using data that has not been validated.
>

Right, that matches what I had in mind, too: you can still have a problem
even though you're in the same page table. I just wanted to confirm that
there's not some odd way to launch out into completely non-page-table
memory.


thanks,
--
John Hubbard
NVIDIA

\
 
 \ /
  Last update: 2020-09-11 00:19    [W:0.240 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site