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


(Background for the systemtap list.  I sent out a plea for s390x help,
and in some private email Ananth sent Heiko my way.)

On 10/28/2011 07:40 AM, Heiko Carstens wrote:

> On Tue, Oct 18, 2011 at 08:56:07AM -0500, David Smith wrote:
> 
> Sorry for late reply.. I was a bit busy. But anyway...
> 
>>> If you would give me a pointer to all the relavant sources/repositories
>>> I might have a look at it. However it will probably take until next week
>>> before I have time to look into it.
>>
>> Thanks!  You can get the entire systemtap source tree with:
>>
>> git clone git://sourceware.org/git/systemtap.git
>>
>> The gitweb viewer is at:
>>
>> http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=summary
>>
>> The particular file to look at is in runtime/loc2c-runtime.h.  That file
>> has all the arch-specific stuff in it, but you shouldn't have any
>> problem finding the s390x specific code.
>>
>> In case you lost this in my first email message, the tricky part here is
>> that the code has to work for both user data and kernel data.  Otherwise
>> I could just call the stock kernel routines.
> 
> The current code won't work for user space or kernel space. The problem in
> kernel space is that the enable write protection for the kernel image, hence
> every store will result in a fault.
> You can avoid that by using the probe_kernel_write() function which will
> bybass the write protection (on s390).

I don't doubt writes are broken.  While writes will need to work, I'd
guess 85%-90% of the time we will call this code to do reads (deref()),
not writes (store_deref()).  So, I'd like to initially focus on reads.

> Also in the current code I do not see how address spaces are switched, so
> it looks to me like all operations are always done in the kernel address
> space.
> 
> I didn't see however the tricky part you mentioned (user space vs kernel
> space). How does the code distinguish if an operation has to be done on
> the kernel space address range or user space address range?

Sigh.  That's the thing - we don't distinguish.  The assumption was made
that calling a function to access user memory would also work for kernel
memory.  In RHEL5-era kernels (2.6.18), that assumption worked for us
with the code that's checked in (originally done by David Wilder from
IBM).  Something has changed in the way the s390x handles memory spaces
since then.

>> P.S.: Is it OK to copy this private email back to the list?
> 
> Sure.


Thanks, I've done this.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


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