Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 12 Jun 2021 14:33:31 -0700 | Subject | Re: [RFC 5/9] iov_iter: Add iov_iter_fault_in_writeable() |
| |
On Sat, Jun 12, 2021 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > Actually, is there any good way to make sure that write fault is triggered > _without_ modification of the data? On x86 lock xadd (of 0, that is) would > probably do it and some of the other architectures could probably get away > with using cmpxchg and its relatives, but how reliable it is wrt always > triggering a write fault if the page is currently read-only?
I wouldn't worry about the CPU optimizing a zero 'add' away (extra work for no gain in any normal situation).
But any architecture using 'ldl/stc' to do atomics would do it in software for at least cmpxchg (ie just abort after the "doesn't match").
Even on x86, it's certainly _possible_ that a non-matching cmpxchg might not have done the writability check, although I would find that unlikely (ie I would expect it to do just one TLB lookup, and just one permission check, whether it then writes or not).
And if the architecture does atomic operations using that ldl/stc model, I could (again) see the software loop breaking out early (before the stc) on the grounds of "value didn't change".
Although it's a lot less likely outside of cmpxchg. I suspect an "add zero" would work just fine even on a ldl/stc model.
That said, reads are obviously much easier, and I'd probably prefer the model for writes to be to not necessarily pre-fault anything at all, but just write to user space with page faults disabled.
And then only if that fails do you do anything special. And at that point, even walking the page tables by hand might be perfectly acceptable - since we know it's going to fault anyway, and it might actually be cheaper to just do it by hand with GUP or whatever.
Linus
| |