Messages in this thread | | | Subject | Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding | From | John Hubbard <> | Date | Thu, 10 Sep 2020 15:17:55 -0700 |
| |
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
| |