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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
