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


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


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