Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe,
>> you recently said there is a bug in the x86_64 support when syscall
>> tracing is enabled. Now I think I stepped on it as well: In order to
>> validate my APIC frequency patches for that arch, I wanted to use LTTng
>> there. But as soon as I start the trace, the latency test fails to run,
>> prematurely exiting due to a segfault.
> Exactly what Gilles sees on his box too, latency segfaulting at startup.
> On mine, the kernel does not even boot.
>  Gdb and the kernel say that user
>> land jumped to address 0, I just yet failed to find out where they come
>> from. I strongly assume LTTng enables syscall tracing, because its
>> entry/exit instrumentations are inside the hook function
>> (syscall_trace_entry/leave).
>> Do you have any further details on your tracing issue? Does may
>> observation correlates with yours?
> Quite frankly, I did not dig the issue that far yet, but yes, my first
> impression is that something is broken in the syscall return path (or
> entry?), and it shows when the return path to user-space is diverted in
> some way, either for security auditing, or likely for tracing like
> you've just reported.

I once got this path into qemu+gdb, but did not trapped a case where the
kernel decides to mess things up and return to NULL. Anyway, this
debugging was not fully reliable, and I will retry soon (once my target
has finished installing a new, full-blown 64-bit distro).

Beside this, I already tried to analyse the return path but found
nothing obvious on first sight. Hmm, wait, if tracing is enabled and we
return from a Xenomai-handled syscall, I guess everything could go wrong
if we then run into syscall_trace_leave over non-root domains, right?
Maybe I should check if this could/actually does happen.

[This bug is annoying. I have a huge pile of new patches here, all just
waiting to be tested, and then this... :-/]


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to