This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: s390x help needed - kernel read faults
- From: David Smith <dsmith at redhat dot com>
- To: Heiko Carstens <heiko dot carstens at de dot ibm dot com>
- Cc: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Systemtap List <systemtap at sourceware dot org>
- Date: Mon, 07 Nov 2011 10:03:19 -0600
- Subject: Re: s390x help needed - kernel read faults
- References: <4E9C76F7.6010802@redhat.com> <20111018052305.GA22831@in.ibm.com> <20111018081753.GA2578@osiris.boeblingen.de.ibm.com> <4E9D8577.9030705@redhat.com> <20111028124058.GA2475@osiris.boeblingen.de.ibm.com> <4EAAF791.1060109@redhat.com> <20111031102934.GA4768@osiris.boeblingen.de.ibm.com>
On 10/31/2011 05:29 AM, Heiko Carstens wrote:
>>> 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.
Sorry for not responding sooner.
I'm not sure why we provided our own functions, that decision was made a
long time ago. If we can't look at the address and know whether it is a
user space or kernel space address, then I don't see much choice than to
break up our memory accesses and require the callers to know whether
they are accessing kernel space or user space.
Thanks for the advice.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)