On Wed, 28 Jan 2026 19:25:46 -0700 Jens Axboe <[email protected]> wrote:
> On Jan 28, 2026, at 5:40 PM, Steven Rostedt <[email protected]> wrote: > > > > > > Jens, > > > > Can you give me an acked-by on this patch and I can take the series through > > my tree. > > On phone, hope this works: > > Acked-by: Jens Axboe <[email protected]> Thanks! > > > Or perhaps this doesn't even need to test the trace_async_init flag and can > > always do the work queue? Does blk_trace ever do tracing at boot up? That > > is, before user space starts? > > Not via the traditonal way of running blktrace. Masami and Yaxiong, I've been thinking about this more and I'm not sure we need the trace_async_init kernel parameter at all. As blktrace should only be enabled by user space, it can always use the work queue. For kprobes, if someone is adding a kprobe on the kernel command line, then they are already specifying that tracing is more important. Patch 3 already keeps kprobes from being an issue with contention of the tracing locks, so I don't think it ever needs to use the work queue. Wouldn't it just be better to remove the trace_async_init and make blktrace always use the work queue and kprobes never do it (but exit out early if there were no kprobes registered)? That is, remove patch 2 and 4 and make this patch always use the work queue. -- Steve
