linux-kernel - Re: [PATCH 1/5] mm: Introduce mm_struct.has

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200923171207.GB9916@ziepe.ca>
Date:   Wed, 23 Sep 2020 14:12:07 -0300
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Jan Kara <jack@...e.cz>
Cc:     Peter Xu <peterx@...hat.com>, John Hubbard <jhubbard@...dia.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Kirill Shutemov <kirill@...temov.name>,
        Hugh Dickins <hughd@...gle.com>,
        Christoph Hellwig <hch@....de>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Leon Romanovsky <leonro@...dia.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned

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?

> 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.

ason