This is a note to let you know that I've just added the patch titled
ring-buffer: Fix a race in rb_time_cmpxchg() for 32 bit archs
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ring-buffer-fix-a-race-in-rb_time_cmpxchg-for-32-bit-archs.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From fff88fa0fbc7067ba46dde570912d63da42c59a9 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Google)" <rostedt@xxxxxxxxxxx>
Date: Tue, 12 Dec 2023 11:53:01 -0500
Subject: ring-buffer: Fix a race in rb_time_cmpxchg() for 32 bit archs
From: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx>
commit fff88fa0fbc7067ba46dde570912d63da42c59a9 upstream.
Mathieu Desnoyers pointed out an issue in the rb_time_cmpxchg() for 32 bit
architectures. That is:
static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
{
unsigned long cnt, top, bottom, msb;
unsigned long cnt2, top2, bottom2, msb2;
u64 val;
/* The cmpxchg always fails if it interrupted an update */
if (!__rb_time_read(t, &val, &cnt2))
return false;
if (val != expect)
return false;
<<<< interrupted here!
cnt = local_read(&t->cnt);
The problem is that the synchronization counter in the rb_time_t is read
*after* the value of the timestamp is read. That means if an interrupt
were to come in between the value being read and the counter being read,
it can change the value and the counter and the interrupted process would
be clueless about it!
The counter needs to be read first and then the value. That way it is easy
to tell if the value is stale or not. If the counter hasn't been updated,
then the value is still good.
Link: https://lore.kernel.org/linux-trace-kernel/20231211201324.652870-1-mathieu.desnoyers@xxxxxxxxxxxx/
Link: https://lore.kernel.org/linux-trace-kernel/20231212115301.7a9c9a64@xxxxxxxxxxxxxxxxxx
Cc: stable@xxxxxxxxxxxxxxx
Cc: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Fixes: 10464b4aa605e ("ring-buffer: Add rb_time_t 64 bit operations for speeding up 32 bit")
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Signed-off-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
kernel/trace/ring_buffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -703,6 +703,9 @@ static int rb_time_cmpxchg(rb_time_t *t,
unsigned long cnt2, top2, bottom2;
u64 val;
+ /* Any interruptions in this function should cause a failure */
+ cnt = local_read(&t->cnt);
+
/* The cmpxchg always fails if it interrupted an update */
if (!__rb_time_read(t, &val, &cnt2))
return false;
@@ -710,7 +713,6 @@ static int rb_time_cmpxchg(rb_time_t *t,
if (val != expect)
return false;
- cnt = local_read(&t->cnt);
if ((cnt & 3) != cnt2)
return false;
Patches currently in stable-queue which might be from rostedt@xxxxxxxxxxx are
queue-5.10/ring-buffer-have-saved-event-hold-the-entire-event.patch
queue-5.10/ring-buffer-fix-memory-leak-of-free-page.patch
queue-5.10/ring-buffer-fix-a-race-in-rb_time_cmpxchg-for-32-bit-archs.patch
queue-5.10/tracing-update-snapshot-buffer-on-resize-if-it-is-allocated.patch
queue-5.10/ring-buffer-fix-writing-to-the-buffer-with-max_data_size.patch
