[lkml]   [2020]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/5] mm: Introduce mm_struct.has_pinned
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...

Jan Kara <>

 \ /
  Last update: 2020-09-24 15:40    [W:0.168 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site