| ... |
    /     /    |y255 |
    \     \    |y256 |
    |-----|    | z1  |
	       | z2  |
               | ... |
	       |z255 |
	       |z256 |
	       |-----|

So the hugetlb page sharing stuff defeats all assumptions and
checks... sigh.
I feel that David's suggestion of just disallowing the use of shared page
tables like this (I mean really does it actually come up that much?) is the
right one then.

I wonder whether we shouldn't just free the PMD after it becomes unshared?
It's kind of crazy to think we'll allow a reuse like this, it's asking for
trouble.

Moving on to another point:

One point here I'd like to raise - this seems like a 'just so'
scenario. I'm not saying we shouldn't fix it, but we're paying a _very
heavy_ penalty here for a scenario that really does require some unusual
things to happen in GUP fast and an _extremely_ tight and specific window
in which to do it.

Plus isn't it going to be difficult to mediate exactly when an unshare will
happen?

Since you can't pre-empt and IRQs are disabled, to even get the scenario to
happen is surely very very difficult, you really have to have some form of
(para?)virtualisation preemption or a NMI which would have to be very long
lasting (the operations you mention in P2 are hardly small ones) which
seems very very unlikely for an attacker to be able to achieve.

So my question is - would it be reasonable to consider this at the very
least a vanishingly small, 'paranoid' fixup? I think it's telling you
couldn't come up with a repro, and you are usually very good at that :)

Another question, perhaps silly one, is - what is the attack scenario here?
I'm not so familiar with hugetlb page table sharing, but is it in any way
feasible that you'd access another process's mappings? If not, the attack
scenario is that you end up accidentally accessing some other part of the
process's memory (which doesn't seem so bad right?).

Thanks, sorry for all the questions but really want to make sure I
understand what's going on here (and can later extract some of this into
documentation also potentially! :)

Cheers, LorenzoBug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast raceLorenzo Stoakes <lorenzo.stoakes@oracle.com> undefinedJann Horn <jannh@google.com> undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefinedŠ ƒÄl