Re: systemtap ARM port status

[Quentin Barnes <qbarnes at urbana dot css dot mot dot com>]

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