Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned

[Linus Torvalds]

On Sat, Sep 26, 2020 at 11:24 PM Leon Romanovsky <leonro@xxxxxxxxxx> wrote:
>
> We won't be able to test the series till Tuesday due to religious holidays.

That's fine. I've merged the series up, and it will be in rc7 later
today, and with an rc8 next week we'll have two weeks to find any
issues.

I did edit Peter's patch 3/4 quite a bit:

 - remove the pte_mkyoung(), because there's no _access_ at fork()
time (so it's very different in that respect to the fault case)

 - added the lru_cache_add_inactive_or_unevictable() call that I think
is needed and Peter's patch was missing

 - split up the "copy page" into its own function kind of like I had
done for my minimal patch

 - changed the comments around a bit (mostly due to that split-up
changing some of the flow)

but it should be otherwise the same and I think Peter will still
recognize it as his patch (and I left it with his authorship and
sign-off).

Anyway, it's merged locally in my tree, I'll do some local testing
(and I have a few other pull requests), but I'll push out the end
result soonish assuming nothing shows up (and considering that I don't
have any pinning loads, I seriously doubt it will, since I won't see
any of the interesting cases).

So if we can get the actual rdma cases tested early next week, we'll
be in good shape, I think.

Btw, I'm not convinced about the whole "turn the pte read-only and
then back". If the fork races with another thread doing a pinning
fast-GUP on another CPU, there are memory ordering issues etc too.
That's not necessarily visible on x86 (the "turn read-only being a
locked op will force serialization), but it all looks dodgy as heck.

I'm also not convinced we really want to support that kind of insane
racy load, but whatever. I left the code in place, but it's something
where we might want to rethink things.

              Linus