https://bugs.kde.org/show_bug.cgi?id=514297

--- Comment #40 from Mark Wielaard <[email protected]> ---
(In reply to mcermak from comment #39)
> Created attachment 191146 [details]
> proposed patch

- madv_guard test moved under memcheck/tests/linux.
  OK.
- Added a configure check for MADV_GUARD_INSTALL.
  OK, depends on newer glibc running on newer kernel, but that should normally
be the case.
- All guardpages related code guarded by #if defined(VGO_linux).
  Nice.
- show_nsegment now uses "" tail on non-linux.
  Good.
- maybe_merge_nsegments uses |= to merge hasGuardPages.
  Looks correct.
- nguardpages_used >= VG_N_GUARDS now panics and tells user what to do
  Nice.
- Already installed guardpage now produces debug log
  Is this really an ERROR?
- guard_page_remove now takes a check Bool, but to logic seems wrong.
  Should probably be:
  if (lo > hi) {
     if (check == True)
        VG_(debugLog)(0,"aspacem", "ERROR: Attempt to remove a non-existing
guard page\n");
     return;
  }
 Otherwise you will never really do the check, and hit the aspacem_assert after
the if statement (if check == True).
- is_guarded_sanity now takes an expected Bool and returns early on
pagemap_io_err instead of barfin.
  Good.
  Should am_open "/proc/self/pagemap" returning -1 also set pagemap_io_err?
  If the sanity checks now fails it call am_exit, maybe these should stay
am_barf to give the user more state?
- is_valid_for now only does a needGuardPageCheck when prot != PROT_NONE
  Correct.
- VG_N_GUARDS is now set directly to VG_(clo_max_guard_pages)  and
VG_(clo_max_guard_pages) is set to VG_(clo_max_threads) unless an explicit
--max-guard-pages is given.
  Seems correct.
- show_guard_pages has been removed.
- priv_aspacemgr.h includes cleaned up
- darwin and freebsd now use GENX_ agai for sys_madvise.
  And POST(sys_madvise) wrapped in #if defined(VGO_linux)
- valid_client_addr no longer special cases on munmap syscall.
  Good.
- No longer special cases PRE_MEM_RASCIIZ in sys_openat.
  Good, but we should bring this up on the developer list to see how to resolve
  the interaction between mprotect and/or guard pages.
- --max-guard-pages documentation in docs/xml/manual-core.xml looks good.
  But should it mention that if --max-threads= is set, then --max-guard-pages
defaults
  to that value, if --max-guard-pages is not set explicitly?

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to