On Mon, Dec 21, 2020 at 7:19 PM Andy Lutomirski luto@kernel.org wrote:
Ugh, this is unpleasantly complicated.
I probably should have phrased it differently, because the case you quote is actually a good one:
I will admit that any API that takes an address and more-or-less-blindly marks it RO makes me quite nervous even assuming all the relevant locks are held. At least userfaultfd refuses to operate on VM_SHARED VMAs, but we have another instance of this (with mmap_sem held for write) in x86: mark_screen_rdonly(). Dare I ask how broken this is? We could likely get away with deleting it entirely.
So I think the basic rule is that "if you hold mmap_sem for writing, you're always safe". And that really should be considered the "default" locking.
ANY time you make a modification to the VM layer, you should basically always treat it as a write operation, and get the mmap_sem for writing.
Yeah, yeah, that's a bit simplified, and it ignores various special cases (and the hardware page table walkers that obviously take no locks at all), but if you hold the mmap_sem for writing you won't really race with anything else - not page faults, and not other "modify this VM".
So mark_screen_rdonly() looks trivially fine to me. I don't think it really necessarily matters any more, and it's a legacy thing for a legacy hardware issue, but I don't think there's any reason at all to remove it either.
To a first approximation, everybody that changes the VM should take the mmap_sem for writing, and the readers should just be just about page fault handling (and I count GUP as "page fault handling" too - it's kind of the same "look up page" rather than "modify vm" kind of operation).
And there are just a _lot_ more page faults than there are things that modify the page tables and the vma's.
So having that mental model of "lookup of pages in a VM take mmap_semn for reading, any modification of the VM uses it for writing" makes sense both from a performance angle and a logical standpoint. It's the correct model.
And it's worth noting that COW is still "lookup of pages", even though it might modify the page tables in the process. The same way lookup can modify the page tables to mark things accessed or dirty.
So COW is still a lookup operation, in ways that "change the writabiility of this range" very much is not. COW is "lookup for write", and the magic we do to copy to make that write valid is still all about the lookup of the page.
Which brings up another mental mistake I saw earlier in this thread: you should not think "mmap_sem is for vma, and the page table lock is for the page table changes".
mmap_sem is the primary lock for any modifications to the VM layout, whether it be in the vma's or in the page tables.
Now, the page table lock does exist _in_addition_to_ the mmap_sem, but it is partly because
(a) we have things that historically walked the page tables _without_ walking the vma's (notably the virtual memory scanning)
(b) we do allow concurrent page faults, so we then need a lower-level lock to serialize the parallelism we _do_ have.
And yes, we have ended up allowing some of those "modify the VM state" to then take the mmap_sem for reading, just because their modifications are slight enough that we can then say "ok, this is a write modification, but the writes it does are protected by the page table lock, we'll just get the mmap_sem for reading". It's an optimization, but it should be considered exactly that: not fundamental, but just a clever trick and an optimization.
It's why I went "userfaultfd is buggy" immediately when I noticed. It basically became clear that "oh, that's an optimization, but it's an *invalid* one", in that it didn't actually work and give the same end result.
So when I said:
Anything that changes RW->RO - like fork(), for example - needs to take the mmap_lock.
I didn't mean that we should consider that RW->RO change to be this complex semantic marker that we should honor and say "ok, because it's a RW->RO change, we need to hold the mmap_sem".
I phrased it really badly, in other words.
What I *should* have said is that *because* userfaultfd is changing the VM layout, it should always act as if it had to take the mmap_sem for writing, and that the RW->RO change is an example of when downgrading that write-lock to a read lock is simply not valid - because it basically breaks the rules about what a lookup (ie a read) can do.
A lookup can never turn a writable page non-writable. A lookup - through COW - _can_ turn a read-only page writable. So that's why "RO->RW" can be ok under the read lock, but RW->RO is not.
Does that clarify the situation when I phrase it that way instead?
Linus