Re: arch/ && tracehook_report_syscall_xxx()

[Roland McGrath]

> We have a lot of code like arch/alpha/kernel/ptrace.c:syscall_trace()
> in arch/ and I can't see how to convert them to use tracehooks.
> 
> The first problem, we don't know which hook should be called, there is
> no entry/exit argument.

These arch maintainers just need to update their code.  Christoph has
started poking arch folks individually about getting up to speed.

IMHO, it is better anyway to use separate entry/exit calls.  For that
change, it is often easy to see how to do it correctly in the assembly code
without really knowing the arch at all.  (There are separate assembly paths
leading to the calls for entry vs exit cases already, just change the
symbol names.  Adding an argument would require a bit of a clue about
assembly on the arch.)

> Still, I think it is better to change this code right now, and call
> ptrace_report_syscall() directly.

I disagree.  Let the arch code get with the modern style.  
It is just a minute's hack for the arch maintainer.

> But, the second problem, there is no "struct pt_regs *".

They can use task_pt_regs(), it gets the same pointer.  It's passed in as
an argument because usually the arch really does have it handy right there
in a register so it's cheaper than recalculating.  (All the non-ancient
arch code uses it there for audit_syscall_{entry,exit} calls too.)

> However. I can't imagine how ptrace_report_syscall(regs) can actually
> use "regs". Perhaps we can remove this argument?

ptrace_report_syscall doesn't need it, it could be removed.  But that is
not apropos to the arch code, which should use tracehook_* properly.

> Hmm... and I can't understand how to change
> arch/mn10300/kernel/ptrace.c:do_syscall_trace(), it does something
> strange with TIF_SINGLESTEP. (maintainers cc'ed).

We can leave those details to the arch maintainers.  That case looks to me
like old hacks for step-over-syscall behavior, which made the opposite
choice (between |0x80 or not for stepping) from what x86 made.  Probably
they just want to match the new "norms" and not try to do anything
different for single-step in syscall tracing.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/