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/CAG48ez3vqbqyWb4bLdpqSUnhwqGo2OQetecNhEGPdCGDr94...
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.