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

> > 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.

Sure it does, _if_ you call set_fs(KERNEL_DS) in advance of any of uaccess
functions. Of course you know that already.

What I don't understand is, why you do not use the set_fs() mechanism and
the in-kernel uaccess functions. Instead you provide your own functions.

Looking alone at the address that needs to be read or written to it's simply
impossible to tell if it's a user space or kernel space address. Just must
specify it.
In addition all the different address space layouts on s390 will make your
life much more difficult. Hence.. use the in-kernel functions, everything
else will break again.

  reply	other threads:[~2011-10-31 10:29 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
2011-10-31 10:29           ` Heiko Carstens [this message]
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=20111031102934.GA4768@osiris.boeblingen.de.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=dsmith@redhat.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).