Re: s390x help needed - kernel read faults

[David Smith <dsmith at redhat dot 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)