Bug 514297 - Track madvise MADV_GUARD_INSTALL in address space manager

Bug 514297 - Track madvise MADV_GUARD_INSTALL in address space manager

Linux 6.13+ and Glibc 2.42+ introduce lightweight stack guard
pages based on madvise() syscall.

The purpose of a guard page is to prevent buggy (or malicious)
code from overrunning a memory region. An inaccessible page
placed at the end of a region will cause a segmentation fault
should the running process try to read or write to it;
well-placed guard pages can trap a number of common buffer
overruns and similar problems. Prior to 6.13, though, the only
way to put a guard page into a process's address space was to set
the protections on one or more pages with mprotect(); that works,
but at the cost of creating a new virtual memory area (VMA) to
contain the affected page(s). Placing a lot of guard pages will
create a lot of VMAs, which can slow down many memory-management
functions.

The new guard-page feature addresses this problem by working at
the page-table level rather than creating a new VMA. A process
can create guard pages with a call to madvise(), requesting the
MADV_GUARD_INSTALL operation. The indicated range of memory will
be rendered inaccessible; any data that might have been stored
there prior to the operation will be deleted. There is an
operation (MADV_GUARD_REMOVE) to remove guard pages as well.

https://lwn.net/Articles/1011366/

With glibc commit a6fbe36b7f31 and others, a guard page is
installed for each new thread.  In the future, guard pages might
be used also for DSOs supporting multiple kernel page sizes.
Except for madvise, a guard page may also be removed via
munmap().  This update introduces the support for this new type
of linux guard pages into Valgrind.

Add new --max-guard-pages command line switch to allow
customizing the maximal count of guard pages Valgrind can handle.
Add new testcase memcheck/tests/linux/madv_guard.

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