[Crash-utility] [RESEND] Re: Check _PAGE_PROTNONE bit in uvtop()

[Dave Anderson]

I'm resending this response to Daisuke's patch because the
mailing list seems to have been confused by the combination
of his original patch and my response to it.  The mailing
list archive has "lost" my response, and shows this instead:

  https://www.redhat.com/archives/crash-utility/2011-April/msg00032.html

which is actually the end of Daisuke's patch posting.  Weird...

Anyway, here's a cut-and-paste of my actual response, which
was sent out individually OK, but I'm guessing that the "digest"
version will show the bogus response above.

----- Original Message -----
> Currently, some of uvtop() functions on x86, x86_64 and ia64 lacks
> checking whether in pte _PAGE_PROTNONE bit is set or not. The flag is
> set to pte when specifying to the corresponding memory space PROT_NONE
> using mprotect(), and then _PAGE_PRESENT bit in the pte is unset in
> order to make hardware cause segmentation fault
> intensionally. Important is the fact that besides _PAGE_PRESENT set,
> _PAGE_PROTNONE indicates the page is present (not swapped out).
>
> The architectures fixed are x86, x86_64 and ia64 except for Xen.
>
> The patchset based on crash 5.1.4 consists of 5 patches, which are
> divided into the ones extending machine dependent data on x86 and
> x86_64, and the ones actually adding _PAGE_PROTNONE checking into each
> uvtop().
>
> defs.h | 6 ++++--
> ia64.c | 6 +++---
> x86.c | 10 ++++++++--
> x86_64.c | 11 +++++++++--
> 4 files changed, 24 insertions(+), 9 deletions(-)

Daisuke,

I have seen this "unknown swap location" on rare occasions when running
"vm -p" on the "ntpd" daemon.  I had determined that the task had done an
mprotect(PROT_NONE), but never got around to fixing it.  Thanks for
addressing this.
  
Also, I will add a display of the new page_protnone field in both the
x86_dump_machdep_table() and x86_64_dump_machdep_table() functions.  

Queued for the next release.

Thanks,
  Dave