On 21.10.24 23:35, Vlastimil Babka wrote:
On 10/21/24 23:20, David Hildenbrand wrote:
I don't think there's really any value in that. There's just no sensible
situation in which a user would care about this I don't think.
Making sure nobody touches an area, and wile doing that somebody already
touched that area? I guess it could be worked around by
mprotect(PROT_NONE),madvise(GUARD),mprotect(PROT_READ|PROT_WRITE) ...
which is not particularly nice :)
And if you're saying 'hey do MADV_DONTNEED if this fails and keep trying!'
then why not just do that in the kernel?
Heh, no!
If user space doesn't expect there to be something, it should *fail*.
That's likely going to be the majority of use cases for guard pages
(happy to be told otherwise). No retry.
And if user space expects there to be something it should zap ahead of
time (which some allocators maybe already do to free up memory after
free()) to then install the guard. No retry.
There is this case where user space might be unsure. There, it might
make sense to retry exactly once.
I've thought so too and the RFC was implemented like this, but Jann came up
with a scenario where a THP can cause the range including our
to-be-installed guard pte to be populated even if the userspace is not
trying to access that exact address, see here:
https://lore.kernel.org/all/CAG48ez3vqbqyWb4bLdpqSUnhwqGo2OQetecNhEGPdCGDr94nbQ@xxxxxxxxxxxxxx/
Ah, THP, I should have realized that myself. Yes indeed, in some cases
we'll have to zap because something was already populated. Not sure how
often it will happen in practice, will depend on the use case.
For use cases like one "one static guard page every 2MiB", I would
assume we install the guard pages early, before expecting any page
faults in that area. Likely there are other ones where it might happen
more frequently.
For uffd that does not apply, because khugepaged backs off with uffd
enabled and the only way to resolve a fault is using uffd -- which
places exactly what was requested by user space. So, no populated PTEs
without actual page faults on the corresponding virtual addresses.
--
Cheers,
David / dhildenb
