linux-kernel - Re: [PATCH v2 15/18] rtla: Make stop

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: <CAAq0SUmW7mUP0iiHMJevR+T6BKHJiFoU4M8sCVjJSRMFnT2J_w@mail.gmail.com>
Date: Wed, 7 Jan 2026 10:24:43 -0300
From: Wander Lairson Costa <wander@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Tomas Glozar <tglozar@...hat.com>, Crystal Wood <crwood@...hat.com>, 
	Ivan Pravdin <ipravdin.official@...il.com>, Costa Shulyupin <costa.shul@...hat.com>, 
	John Kacur <jkacur@...hat.com>, Tiezhu Yang <yangtiezhu@...ngson.cn>, 
	"open list:Real-time Linux Analysis (RTLA) tools" <linux-trace-kernel@...r.kernel.org>, 
	"open list:Real-time Linux Analysis (RTLA) tools" <linux-kernel@...r.kernel.org>, 
	"open list:BPF [MISC]:Keyword:(?:b|_)bpf(?:b|_)" <bpf@...r.kernel.org>
Subject: Re: [PATCH v2 15/18] rtla: Make stop_tracing variable volatile

On Tue, Jan 6, 2026 at 1:05 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue,  6 Jan 2026 08:49:51 -0300
> Wander Lairson Costa <wander@...hat.com> wrote:
>
> > Add the volatile qualifier to stop_tracing in both common.c and
> > common.h to ensure all accesses to this variable bypass compiler
> > optimizations and read directly from memory. This guarantees that
> > when the signal handler sets stop_tracing, the change is immediately
> > visible to the main program loop, preventing potential hangs or
> > delayed shutdown when termination signals are received.
>
> In the kernel, this is handled via the READ_ONCE() macro. Perhaps rtla
> should implement that too.
>

I considered that, but, in this use case, I saw no point because it
didn't bring any advantage and volatile was simpler.
Furthermore, as Crystal pointed out, using volatile for variables
shared with signals is a pretty standard practice.

> -- Steve
>