This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap ARM port status
Hi Roland! I don't think we've swapped mail in some time, maybe
even going back to the gmake alpha devel mailing list back in the
'90s.
:-) You'll forgive me if I don't recall. I've always been lousy at even
noticing who it is I'm conversing with in email. And I've been actively
repressing memories associated with make for far over a decade now. ;-)
Oh, I don't fault you at all. I'm the same way with names, just
absolutely horrible, and with e-mail too.
I think though if I dug up some of our good discussions from back
then, I'm pretty sure you'd recall one or two.
Well, gee, I think that's a real first for me. I'm often told to
take a discussion off a mailing list to e-mail, not the other way
around!
Technical details almost always belong on a mailing list. Then
everything is archived for future reference. Moreover, anyone
with something to contribute can help. It's rarely the case that
exactly one person is the one and only person who can figure out
any particular problem most easily, let alone that one can guess a
priori who that person is.
If Martin didn't know the answer off the top of his head, I would
have certainly taken the technical issues to the list.
The loc2c-runtime.h macros deref and store_deref are intended for
dealing with kernel addresses only. Any appearance of "user" in
their definitions is a machine-specific implementation detail that
should not concern you.
I does concern me if I'm trying to understand and port the code! :-)
The specified use of these macros is for kernel-space addresses,
with unspecified behavior when given a user-space address.
Ah, ha! Some pieces are starting to come together. I get this
comment block now from loc2c-runtime.h:
On most machines, the asm/uaccess.h macros __get_user_asm and
__put_user_asm do exactly the low-level work we need to access
memory with fault handling, and are not actually specific to
user-address access at all. Each machine's definition of deref
and deref_store here must work right for kernel addresses, and
can use whatever existing machine-specific kernel macros are
convenient.
As I discovered the hard way, this assertion about the
__{get|put}_user_asm*() macros is apparently not true on ARM, hence
my problem.
Only knowing the ARM port to date, and from their names, I would not
have guessed that the opposite is true in the general case, that
those macros could safely be used on kernel addresses on most other
architectures. (And the whole bit with __user and such was a good
red herring.) Sigh, another case of inappropriately named kernel
services confusing their purpose. I suppose it's considered an
implementation detail which way they happen to work though.
I would think then that the ARM version of __get_user_asm_byte()
macro is being (overly?) pedantic. There's no need for it to use
the user-only space byte load instruction, "ldrbt". It could have
used the general byte load "ldrb" instruction. As I now understand
it, all user-space addresses prior to accessing by the kernel must
be checked with access_ok() anyways to make sure the address is in
the range that a user space process can legally access.
So I think all I have to do to properly port the deref() macro
for ARM is to copy the ARM's __{get|put}_user_asm_{byte|half|word}()
macros to loc2c-runtime.h, rename them to the _stp_* variety, and
have them use the "ldrb", "strb", "ldr", and "str" instructions.
Aside from the Sytemtap issue, I would like to understand why
fs/open.c:sys_access() "filename" parameter is tagged with "__user",
but it seems to be passed a kernel address. I thought for sure this
always meant that such a qualified pointer is expected to be holding
a user-space only address. Is my understanding of this qualifier in
Linux kernel programming errant, or is the ARM port broken in this
way?
[...]
Thanks, Roland
Quentin