[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d40f598776e7995c9f1559514e89ccff51d91f9c.camel@redhat.com>
Date: Tue, 06 Jan 2026 11:47:56 -0600
From: Crystal Wood <crwood@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>, Wander Lairson Costa
<wander@...hat.com>
Cc: Tomas Glozar <tglozar@...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, 2026-01-06 at 11:05 -0500, Steven Rostedt 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.
Or just get it from tools/include/linux/compiler.h. No need to reinvent
the wheel (even though several other tools do).
That said, signal safety is a pretty routine use for volatile.
-Crystal
Powered by blists - more mailing lists