https://bugs.kde.org/show_bug.cgi?id=514297
--- Comment #20 from Mark Wielaard <[email protected]> --- Hi Martin, (In reply to mcermak from comment #18) > Created attachment 190316 [details] > wip patch As we discussed on irc if you keep an fd around (please use Int instead of SysRes), then make sure to call VG_(safe_fd) so it is moved out of the application range (otherwise an application might accidentially use it or close it). > Hello Philippe, thank you for checking my patch! I've been looking into > it. This new guard pages mechanism was introduced in glibc upstream commit > a6fbe36b7f31292981422692236465ab56670ea9. That is glibc-2.42. IMHO The > oldest Fedora that can be used to test this with real life workloads is > Fedora-44 (that's kernel-6.19.5-300.fc44.x86_64 and glibc-2.43-2.fc44). > I've used the following systemtap script to monitor the madvise syscall > system-wide: > > # stap -ve 'probe syscall.madvise {printdln(" ", advice_str, execname())}' Would be interesting to see the print_ustack (); for that to know what user space code decides to use guard pages. > Apparently, a guard page installation is rare. One can trigger it with e.g. > `yum makecache`, some curl invocations or when cloning the valgrind sources > with git. But typically just once per process lifetime. Right so glibc 2.42+ with linux kernel 6.13+ installs stack guard pages using MADV_GUARD_INSTALL: https://sourceware.org/cgit/glibc/commit/?id=a6fbe36b7f31292981422692236465ab56670ea9 This is why e.g. memcheck/tests/descr_belowsp.vgtest fails on such systems. > You are right that is_valid_for() may become expensive with my patch, but > only where nsegments[i].hasGuardPages is True. Having said all that, in > practice such condition is met with just a very few segments - typically > zero or one in practice. So I'm not overly worried about it. I might > easily be mistaken though. Please let me know if you disagree. As a prototype using /proc/self/pagemap and seeking in it to figure out whether an address falls into a page guard is fine. But it would be good to no need to do any syscalls for the actual check. When setting the nsegment.hasGuardPages in am_notify_madv_guard_install you also get the addres (and len) of the actual guard page set. You could just store those in a local data structure that can be checked by belongs_to_guard_page. You also need to remove them from notify_core_and_tool_of_madv_guard_remove of course. That would remove all speed concerns imho. You still would like to use /proc/self/pagemaps for sanity checks though (--sanity-level=3 testing) -- You are receiving this mail because: You are watching all bug changes.
