Right.
Right.
Maybe. I don't think it has to be the only choice, or that the DS layer
exactly has to decide this ahead of time.
The other option is to have some spare free buffers ready to swap into the
DS pointers quickly so the old buffers can be copied with ongoing traces
re-enabled.
A tracer taking kernel data is kernel-internal by definition. I think it's
ok to rely on a kernel-internal tracer to meet its obligations.
For a tracer only taking user data, there is no need to get a response from
it quickly at all. You can just disable user tracing in the interrupt
handler, and set TIF_NOTIFY_RESUME. When you have kernel tracing enabled
too and have to filter, that might require quickly swapping in a new
kernel-only tracing buffer to preserve the full one with the user-mode
data. Then, in the do_notify_resume code that checks TIF_NOTIFY_RESUME,
you can process any necessary buffer management code to re-enable the
user-mode tracing.
I disagree. It is certainly not inevitable that the only things that can
be implemented will be lossy.
Nothing about it has to be "insecure". I think "incomplete traces" is
being a bit dramatic when it just means the trace of the buffer management
code between when buffers fill and when they've been swapped or drained
into other buffers so tracing can be reenabled.
That's true. Any time you need filtering, then the circular buffer might
fill up with kernel-mode entries and lose all your user-mode ones. I think
the only case there's a way to optimize is when you fill up while in kernel
mode and all kernel-mode tracers only want circular. Then you can switch
buffers and let it fill up in circular mode, and then switch back to
filtering when returning to user mode.
Yes, something like that. I figure the DS layer would deal with disabling
tracing and making a callback with interrupts disabled. It would then make
it easy (callback return value, more calls, whatever API) to either leave
it disabled or offer another buffer to reenable tracing before returning
and enabling interrupts. Also make it easy to reenable later (if someone
wants a callback that posts a softirq or whatever).
That callback could be used to set TIF_NOTIFY_RESUME so as to do later
reenabling for user-only tracing. But possibly that would just be rolled
into the DS layer, so it has a non-interrupt callback for user-only tracers.
Well, however they want. For kernel-only tracers, whatever they're part of
may already have a mechanism that's convenient to get wired tracing buffer
space at interrupt level. There might come along some generic such thing
that is easy to tie into. Whatever fits the use.
For purely user-only tracing features, there is a lot more latitude to
implement it however you want, since you don't need to worry about
interrupt level and all that. In a callback from do_notify_resume, you can
do anything you like in kernel mode in that thread's context, block it if
you need to, etc.. Re-enable user tracing and return to user mode only
whenever you are ready with fresh buffers, whatever that entails.
Thanks,
Roland
--
