public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	       Systemtap List <systemtap@sourceware.org>
Subject: Re: s390x help needed - kernel read faults
Date: Fri, 28 Oct 2011 18:43:00 -0000	[thread overview]
Message-ID: <4EAAF791.1060109@redhat.com> (raw)
In-Reply-To: <20111028124058.GA2475@osiris.boeblingen.de.ibm.com>

(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)

  parent reply	other threads:[~2011-10-28 18:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-17 18:42 David Smith
     [not found] ` <20111018052305.GA22831@in.ibm.com>
     [not found]   ` <20111018081753.GA2578@osiris.boeblingen.de.ibm.com>
     [not found]     ` <4E9D8577.9030705@redhat.com>
     [not found]       ` <20111028124058.GA2475@osiris.boeblingen.de.ibm.com>
2011-10-28 18:43         ` David Smith [this message]
2011-10-31 10:29           ` Heiko Carstens
2011-11-07 16:03             ` David Smith
2011-11-07 17:18               ` Mark Wielaard
2011-11-08 12:18                 ` Heiko Carstens
2011-11-26  1:50                 ` Mark Wielaard
2011-11-28 11:20                   ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EAAF791.1060109@redhat.com \
    --to=dsmith@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).