[patch] Fix gcore writer for -Wl,-z,relro (PR corefiles/11804)
Ulrich Weigand
uweigand@de.ibm.com
Thu Sep 23 14:48:00 GMT 2010
Jan Kratochvil wrote:
> There was a hint
> http://sourceware.org/bugzilla/show_bug.cgi?id=11804#c12
> it may not always work right but that would be just a Linux kernel bug so that
> GDB part should be OK. Also it cannot be a regression, only more pages may be
> written out with this patch.
[ I've been tracking down a Linux on z customer problem that turns out to be
exactly the same issue -- thanks for working on this! ]
It appears there are at least two problems with this approach currently
being discussed:
- The "dirty" pages count in /proc/.../smaps is sometimes wrong. This is
because the kernel currently only checks the per-PTE dirty bit, and not
the per-page dirty bit. This is drastically wrong on System z, because
the platform *only* has a per-page hardware dirty bit; per-PTE dirty bit
checks will always return "clean". But on other systems there's a chance
of mis-indication of the dirty state as well (e.g. if the page was dirtied
by a syscall, or if a dirty page was swapped out, swapped back in, and
subsequently removed from swap).
This can indeed be considered a pure kernel bug that needs to be fixed.
- Even with the dirty accounting fixed, there are *still* cases where a page
is genuinely clean as far as memory-management is concerned, but it was
modified as compared to the file contents anyway.
This happens if a page was swapped out and back in, but its contents
remain present in swap space until the latter is reused (so-called "swap
cache" pages). These are legitimately considered clean pages because
they can be simply dropped if needed -- the content is still there on
the swap device.
To fix the second problem, it seems GDB will need to pursue a different
approach, for example by checking whether a mapping contains only file-backed
or also any anonymous pages (I'm told by kernel folks that swap cache pages
also count as anonymous). However, this information is not readily available
in the general case (it's in /proc/kpageflags, but that's root-only, and it
is also in /proc/.../numa_maps, but only if NUMA support is enabled ...).
One proposal is to add a count of anonymous pages to /proc/.../smaps:
http://marc.info/?l=linux-kernel&m=128460743123381&w=2
If that goes in, I guess your patch should consider the new Anonymous:
field instead of (or maybe in addition to?) Shared_Dirty and Private_Dirty.
(Swap needs to be considered as well in either case.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
More information about the Gdb-patches
mailing list