Thread (62 messages) 62 messages, 11 authors, 2020-09-15

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

From: John Hubbard <jhubbard@nvidia.com>
Date: 2020-09-10 22:18:12
Also in: linux-arch, linux-arm-kernel, linux-mm, linux-s390, linux-um, lkml, sparclinux

On 9/10/20 3:11 PM, Jason Gunthorpe wrote:
On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help