linux-kernel - Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG

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: <YcVSUmfzTrhjZapc@casper.infradead.org>
Date:   Fri, 24 Dec 2021 04:53:38 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     David Hildenbrand <david@...hat.com>, Jan Kara <jack@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Nadav Amit <namit@...are.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Yang Shi <shy828301@...il.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Roman Gushchin <guro@...com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Peter Xu <peterx@...hat.com>,
        Donald Dutile <ddutile@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Oleg Nesterov <oleg@...hat.com>, Linux-MM <linux-mm@...ck.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via
 FAULT_FLAG_UNSHARE (!hugetlb)

On Thu, Dec 23, 2021 at 10:53:09PM -0400, Jason Gunthorpe wrote:
> On Thu, Dec 23, 2021 at 12:21:06AM +0000, Matthew Wilcox wrote:
> > On Wed, Dec 22, 2021 at 02:09:41PM +0100, David Hildenbrand wrote:
> > > Right, from an API perspective we really want people to use FOLL_PIN.
> > > 
> > > To optimize this case in particular it would help if we would have the
> > > FOLL flags on the unpin path. Then we could just decide internally
> > > "well, short-term R/O FOLL_PIN can be really lightweight, we can treat
> > > this like a FOLL_GET instead". And we would need that as well if we were
> > > to keep different counters for R/O vs. R/W pinned.
> > 
> > FYI, in my current tree, there's a gup_put_folio() which replaces
> > put_compound_head:
> > 
> > static void gup_put_folio(struct folio *folio, int refs, unsigned int flags)
> > {
> >         if (flags & FOLL_PIN) {
> >                 node_stat_mod_folio(folio, NR_FOLL_PIN_RELEASED, refs);
> >                 if (hpage_pincount_available(&folio->page))
> >                         hpage_pincount_sub(&folio->page, refs);
> >                 else
> >                         refs *= GUP_PIN_COUNTING_BIAS;
> >         }
> > 
> >         folio_put_refs(folio, refs);
> > }
> > 
> > That can become non-static if it's needed.  I'm still working on that
> > series, because I'd like to get it to a point where we return one
> > folio pointer instead of N page pointers.  Not quite there yet.
> 
> I'm keen to see what that looks like, every driver I'm working on that
> calls PUP goes through gyrations to recover contiguous pages, so this
> is most welcomed!

I'm about to take some time off, so alas, you won't see it any time
soon.  It'd be good to talk with some of the interested users because
it's actually a pretty tricky problem.  We can't just return an array
of the struct folios because the actual memory you want to access
might be anywhere in that folio, and you don't want to have to redo
the lookup just to find out which subpages of the folio are meant.

So I'm currently thinking about returning a bio_vec:

struct bio_vec {
        struct page     *bv_page;
        unsigned int    bv_len;
        unsigned int    bv_offset;
};

In the iomap patchset which should go upstream in the next merge window,
you can iterate over a bio like this:

        struct folio_iter fi;

        bio_for_each_folio_all(fi, bio)
                iomap_finish_folio_read(fi.folio, fi.offset, fi.length, error);

There aren't any equivalent helpers for a bvec yet, but obviously we can
add them so that you can iterate over each folio in a contiguous range.

But now that each component in it is variable length, the caller can't
know how large an array of bio_vecs to allocate.

1. The callee can allocate the array and let the caller free it when it's
   finished
2. The caller passes in a (small, fixed-size, on-stack) array of bio_vecs
   over (potentially) multiple calls.
3. The caller can overallocate and ignore that most of the array isn't
   used.

Any preferences?  I don't like #3.