On Thu 24-09-20 11:02:37, Jason Gunthorpe wrote: > On Thu, Sep 24, 2020 at 09:44:09AM +0200, Jan Kara wrote: > > > 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. > > I mean, the page could have been freed and already reallocated with a > positive refcount, so the add_unless check isn't protective. > > The add_unless prevents the page from being freed. The 2nd pte read > ensures it wasn't already freed/reassigned before the pin. Ah, right! > If something drives the page refcount to zero then it is already > synchronized with GUP fast because of the atomic add_unless, no need > to re-check the pte for that case?? But I don't know what the DAX case > is you mentioned. DAX needs to make sure no new references (including GUP-fast) can be created for a page before truncating page from a file and freeing it. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR