[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220720134531.400b87af@gandalf.local.home>
Date: Wed, 20 Jul 2022 13:45:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Daniel Bristot de Oliveira <bristot@...nel.org>
Cc: Wim Van Sebroeck <wim@...ux-watchdog.org>,
Guenter Roeck <linux@...ck-us.net>,
Jonathan Corbet <corbet@....net>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Marco Elver <elver@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Shuah Khan <skhan@...uxfoundation.org>,
Gabriele Paoloni <gpaoloni@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Clark Williams <williams@...hat.com>,
Tao Zhou <tao.zhou@...ux.dev>,
Randy Dunlap <rdunlap@...radead.org>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-devel@...r.kernel.org
Subject: Re: [PATCH V6 02/16] rv: Add runtime reactors interface
On Wed, 20 Jul 2022 19:37:58 +0200
Daniel Bristot de Oliveira <bristot@...nel.org> wrote:
> > That has logic that looks to require a lock to protect things from changing
> > from underneath.
>
> ack, so the only variable I see we can use READ_ONCE/WRITE_ONCE is the reacting_on...
WRITE_ONCE() does not supply memory barriers, which you may need.
I'm only at patch 3, I'm not sure what the full requirements of that is.
-- Steve
Powered by blists - more mailing lists