Re: [PATCH 5/5] mm/thp: Split huge pmds/puds if they're pinned when fork()

[John Hubbard]

On 9/23/20 8:44 AM, Peter Xu wrote:
> On Wed, Sep 23, 2020 at 04:01:14PM +0200, Jan Kara wrote:
> > On Wed 23-09-20 09:50:04, Peter Xu wrote:
...
> > > > But the problem is that if you apply mm->has_pinned check on file pages,
> > > > you can get false negatives now. And that's not acceptable...
> > >
> > > Do you mean the case where proc A pinned page P from a file, then proc B
> > > mapped the same page P on the file, then fork() on proc B?
> >
> > Yes.

aha, thanks for spelling out the false negative problem.

> > > If proc B didn't explicitly pinned page P in B's address space too,
> > > shouldn't we return "false" for page_likely_dma_pinned(P)?  Because if
> > > proc B didn't pin the page in its own address space, I'd think it's ok to
> > > get the page replaced at any time as long as the content keeps the same.
> > > Or couldn't we?
> >
> > So it depends on the reason why you call page_likely_dma_pinned(). For your
> > COW purposes the check is correct but e.g. for "can filesystem safely
> > writeback this page" the page_likely_dma_pinned() would be wrong. So I'm
> > not objecting to the mechanism as such. I'm mainly objecting to the generic
> > function name which suggests something else than what it really checks and
> > thus it could be used in wrong places in the future... That's why I'd
> > prefer to restrict the function to PageAnon pages where there's no risk of
> > confusion what the check actually does.
>
> How about I introduce the helper as John suggested, but rename it to
>
>    page_maybe_dma_pinned_by_mm()
>
> ?
>
> Then we also don't need to judge on which is more likely to happen (between
> "maybe" and "likely", since that will confuse me if I only read these words..).

You're right, it is too subtle of a distinction after all. I agree that sticking
with "_maybe_" avoids that confusion.


> I didn't use any extra suffix like "cow" because I think it might be useful for
> things besides cow.  Fundamentally the new helper will be mm-based, so "by_mm"
> seems to suite better to me.
>
> Does that sound ok?

Actually, Jan nailed it. I just wasn't understanding his scenario, but now that
I do, and considering your other point about wording, I think we end up with:

    anon_page_maybe_pinned()

as a pretty good name for a helper function. (We don't want "_mm" because that
refers more to the mechanism used internally, rather than the behavior of the
function. "anon_" adds more meaning.)

...now I better go and try to grok what Jason is recommending for the new
meaning of FOLL_PIN, in another tributary of this thread. I don't *think* it affects
this naming point, though. :)

thanks,
--
John Hubbard
NVIDIA