On Wed 23-09-20 14:12:07, Jason Gunthorpe wrote: > On Wed, Sep 23, 2020 at 04:20:03PM +0200, Jan Kara wrote: > > > I'd hate to take spinlock in the GUP-fast path. Also I don't think this is > > quite correct because GUP-fast-only can be called from interrupt context > > and page table locks are not interrupt safe. > > Yes, IIRC, that is a key element of GUP-fast. Was it something to do > with futexes? Honestly, I'm not sure. > > and then checking page_may_be_dma_pinned() during fork(). That should work > > just fine AFAICT... BTW note that GUP-fast code is (and this is deliberated > > because e.g. DAX depends on this) first updating page->_refcount and then > > rechecking PTE didn't change and the page->_refcount update is actually > > done using atomic_add_unless() so that it cannot be reordered wrt the PTE > > check. So the fork() code only needs to add barriers to pair with this. > > It is not just DAX, everything needs this check. > > After the page is pinned it is prevented from being freed and > recycled. After GUP has the pin it must check that the PTE still > points at the same page, otherwise it might have pinned a page that is > alreay free'd - and that would be a use-after-free issue. I don't think a page use-after-free is really the reason - we add page reference through page_ref_add_unless(page, x, 0) - i.e., it will fail for already freed page. It's more about being able to make sure page is not accessible anymore - and for that modifying pte and then checking page refcount it *reliable* way to synchronize with GUP-fast... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
