Re: [patch] Fix gcore writer for -Wl,-z,relro (PR corefiles/11804)

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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