linux-kernel - Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260129222608.7000bffd@robin>
Date: Thu, 29 Jan 2026 22:26:08 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Yaxiong Tian <tianyaxiong@...inos.cn>
Cc: Jens Axboe <axboe@...nel.dk>, mhiramat@...nel.org,
 mathieu.desnoyers@...icios.com, corbet@....net, skhan@...uxfoundation.org,
 linux-trace-kernel@...r.kernel.org, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous
 when trace_async_init set

On Fri, 30 Jan 2026 11:09:26 +0800
Yaxiong Tian <tianyaxiong@...inos.cn> wrote:

> > thought|trace_eval_sync()|'s|destroy_workqueue()|would wait for all 
> > tasks to complete, but it seems that might not be the case. From this, 
> > if the above conclusion is true, then strictly speaking, tasks 
> > using|queue_work(xx)|cannot be guaranteed to finish before the init 
> > process executes. If it's necessary to strictly ensure initialization 
> > completes before user space starts, 
> > using|async_synchronize_full()|or|async_synchronize_full_domain()|would 
> > be better in such scenarios.  
> I need to double-check this issue—theoretically, it shouldn't exist. But 
> I'm not sure why the print appeared at the 14-second mark.

Use trace_printk() instead. printk now has a "deferred" output. I'm not
sure if the timestamps of when it prints is when the print took place
or when it got to the console :-/

-- Steve


> >
> > Of course, the situation described above is an extreme case. I don't 
> > oppose this approach; I only hope to make the startup faster for 
> > ordinary users who don’t use trace, while minimizing the impact on 
> > others as much as possible.
> >