Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 25 Sep 2020 21:41:36 -0300
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Peter Xu <peterx@redhat.com>, John Hubbard <jhubbard@nvidia.com>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jan Kara <jack@suse.cz>, Michal Hocko <mhocko@suse.com>,
        Kirill Tkhai <ktkhai@virtuozzo.com>,
        Kirill Shutemov <kirill@shutemov.name>,
        Hugh Dickins <hughd@google.com>,
        Christoph Hellwig <hch@lst.de>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Leon Romanovsky <leonro@nvidia.com>,
        Jann Horn <jannh@google.com>
Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned
Message-ID: <20200926004136.GJ9916@ziepe.ca>
References: <20200923170759.GA9916@ziepe.ca>
 <20200924143517.GD79898@xz-x1>
 <20200924165152.GE9916@ziepe.ca>
 <20200924175531.GH79898@xz-x1>
 <20200924181501.GF9916@ziepe.ca>
 <20200924183418.GJ79898@xz-x1>
 <20200924183953.GG9916@ziepe.ca>
 <20200924213010.GL79898@xz-x1>
 <CAHk-=wgz5SXKA6-uZ_BimOP1C7pHJag0ndz=tnJDAZS_Z+FrGQ@mail.gmail.com>
 <CAHk-=whDSH_MRMt80JaSwoquzt=1nQ-0n3w0aVngoWPAc10BCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=whDSH_MRMt80JaSwoquzt=1nQ-0n3w0aVngoWPAc10BCw@mail.gmail.com>
Precedence: bulk

On Fri, Sep 25, 2020 at 02:06:59PM -0700, Linus Torvalds wrote:
> On Fri, Sep 25, 2020 at 12:56 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > And honestly, since this is all getting fairly late in the rc, and it
> > took longer than I thought, I think we should do the GFP_ATOMIC
> > approach for now - not great, but since it only triggers for this case
> > that really should never happen anyway, I think it's probably the best
> > thing for 5.9, and we can improve on things later.
> 
> I'm not super-happy with this patch, but I'm throwing it out anyway, in case
> 
>  (a) somebody can test it - I don't have any test cases

It looks like it will work and resolve the RDMA case that triggered
this discussion. I will send it to our testers, should hear back
around Monday.

They previously said Peter's v1 patch worked, expecting the same here,
unless something unexpected hits the extra pre-conditions.

Though, we might hit the THP case and find it fails...

>  (b) somebody can find issues and improve on it

The THP hunks from Peter's series looked pretty straightforward, I'd
include at least the PMD one.

As a tiny optimization, the preconditions in copy_normal_page() could
order the atomics last to try and reduce the atomics done per fork.

> I'm happy to take Peter's series too, this is more of an alternative
> simplified version to keep the discussion going.

I don't completely grok the consequences of the anon_vma check. We
can exclude file backed mappings as they are broken for pinning
anyhow, so what is left that could be MAP_PRIVATE of a non-anon_vma?

Feels obscure, probably OK. If something does break userspace could
use MAP_SHARED and be fixed.

Otherwise, I do prefer Peter's version because of the GFP_KERNEL. To
touch on your other email..

It was my hope we could move away from the "This should never
happen". From a RDMA POV this idea was sort of managable years ago,
but now I have folks writing data science/ML software in Python that
deep under the libraries use RDMA and has pinned pages. It was a
Python program that detected this regression.

Having all that "just work" regardless of what foolish stuff happens
in the Python layer is very appealing.

Jason