[Crash-utility] [RESEND] Re: Check _PAGE_PROTNONE bit in uvtop()
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