This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: User Memory Read Failure Question
- From: Josh Stone <jistone at redhat dot com>
- To: Daniel Heller <daniel dot heller at gmail dot com>, systemtap at sourceware dot org
- Date: Mon, 24 Aug 2015 10:58:57 -0700
- Subject: Re: User Memory Read Failure Question
- Authentication-results: sourceware.org; auth=none
- References: <CAGY_4kCbt+zdWS=a_8XRdCHPyLYzOn6A6P=67j87x-j7YaCiJw at mail dot gmail dot com>
On 08/24/2015 05:07 AM, Daniel Heller wrote:
> Since I am tracing an interpreter (Node.js 0.10) whose behavior I
> don't fully understand, it's possible that the process itself is
> changing permissions on the pages dynamically, causing the reads to
> fail. I haven't been able to disprove this possibility.
Try to probe syscall.mprotect, or even just strace -e mprotect.
> (a) Whether Linux may be unmapping the pages (but leaving them
> resident) for access detection, and whether if that happened,
> SystemTap would fail user reads to avoid potential recursive faulting
> behavior.
I'm not sure how this unmapping would happen. If it's really out of the
process' memory map, then there's no access anymore. Now, getting paged
out, or never having paged in, is totally possible...
> (b) Whether there may be reasons for systemtap read failures other
> than invalid mappings that I haven't anticipated but would be able to
> check for.
I think it's most likely that the memory simply isn't paged in at that
time. SystemTap's kernel handlers run in atomic context, so they can't
wait for a page fault to be serviced.
But if you poked the same process memory from outside, that ought to
have paged it in, so if it still fails I'm not sure...
You might have better luck with stap --runtime=dyninst, where all the
probe handlers will run directly in-process, so all memory access is
exactly as capable as the process itself. (e.g. paging is fine.) But
dyninst mode only works for scripts without any kernel probes, and it
only works on targeted processes (-x / -c) and their children, not
systemwide. Plus some features aren't developed there yet, especially
backtracing. If that's acceptable, please try it out!
> (c) Whether there is a good recipe for getting at the page-level
> permissions in the VM, from SystemTap context or otherwise (this would
> of course be platform-specific; I can dig in and embed C if need be,
> but I'm not experienced with the Linux VM).
I don't think we have anything canned like that, but it sounds like a
good idea for a tapset function! Something like:
function addr_vm_flags:long(addr:long) %{
struct vm_area_struct *vma;
unsigned long addr = STAP_ARG_addr;
vma = find_vma_intersection(current->mm, addr, addr+1);
STAP_RETURN(vma ? vma->vm_flags : VM_NONE);
%}
(only lightly tested here)
Or maybe pgprot_val(vma->vm_page_prot) is more useful, I'm not sure.