This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: s390x help needed - kernel read faults


On Sat, 2011-11-26 at 02:50 +0100, Mark Wielaard wrote:
> So I split our deref and store_deref into uderef/kderef and
> store_u/kderef that are now used when user or kernel addresses are
> accessed. For most architectures these are equal. But for s390x I
> replaced our custom accessor functions with with standard s390 kernel
> __get_user() and __put_user() functions and then wrap those in get_fs()
> set_fs() calls to switch between user/kernel space addresses. See below.
> 
> Tested against 2.6.18 (rhel5) and 2.6.32 (rhel6) kernels. It improves
> the make installcheck results a lot.
> 
> There is still some work to do for the user space dwarf unwinder.

This has been fixed, the unwinder now also splits its user/kernel
address view completely. There was also a generic bug in the vma tracker
that could in theory hit on any architecture. There is still an issue
with PIE executables on s390x that I haven't tracked down yet. But
excluding PIE executables both user and kernel backtracing and symbol
tracking seems to be on par with other architectures now.

Cheers,

Mark

commit 3c6dd54efb6de5b4d55e073c8d5884440aece135
Author: Mark Wielaard <mjw@redhat.com>
Date:   Sat Nov 26 22:21:22 2011 +0100

Pass through user flag into all of unwinder.
    
runtime/unwind.c relied on passing of struct task being not NULL
to see whether to access user space. In practice tsk was always
either NULL or current. And not all bits of the unwinder checked
it. Now we just pass a user flag and push it down to every
function that needs it.


commit bde342310dd6b1a7e247a0dc40089b25f045552a
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Nov 28 12:06:39 2011 +0100

_stp_vma_mmap_cb: Really mean that we are only interested in the first
load.
    
There was a chance our test for whether this was the first load of the
whole module that is executable could miss a second load, which would
override the original start address. Fix that by explicitly checking
whether we already registered this module or not.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]