https://bugs.kde.org/show_bug.cgi?id=514297
--- Comment #15 from Mark Wielaard <[email protected]> --- (In reply to mcermak from comment #11) > If this is a way to go then I can imagine adding a new flag (such as maybe > hasMG as in madvise guard page) to the NSegment struct in > include/pub_tool_aspacemgr.h and working with that. > madvise(MADV_GUARD_INSTALL) doesn't change the memory protection flags, so > that the existing hasR, hasW, and hasX would continue tracking it in > aspacemgr, and so MADV_GUARD_REMOVE would just unset this new flag and > client execution would continue? (In reply to mcermak from comment #12) > Not sure about the granularity of this solution though, since NSegment > covers a VMA (as in item in /proc/pid/maps), which may cover mutiple pages... I think this is the way to go, but since there could be multiple guard pages per VMA I would just add a Bool to the NSegment struct (for VGO_linux only) hasGuardPages. Then just have a simple data structure containing all the guard page addresses (sorted array of Addr?) When a guard page is added set the hasGuardPages of the corresponding NSegments/VMA. It is a little more work when a guard page is removed, you'll have to lookup if there are any other guard pages left between VMA start/end, but I assume that adding/removing guard pages isn't done often. -- You are receiving this mail because: You are watching all bug changes.
