linux-kernel - Re: [PATCH] ring-buffer: Fix persistent buffer when commit page is the reader page

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: <d60729c2-9fb4-4fa7-9e4b-070127d8943e@tasossah.com>
Date: Wed, 14 May 2025 09:20:12 +0300
From: Tasos Sahanidis <tasos@...ossah.com>
To: Steven Rostedt <rostedt@...dmis.org>, LKML
 <linux-kernel@...r.kernel.org>,
 Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] ring-buffer: Fix persistent buffer when commit page is
 the reader page

On 2025-05-13 18:50, Steven Rostedt wrote:
> To trigger this bug:
> 
>   # echo 1 > /sys/kernel/tracing/instances/boot_mapped/events/syscalls/sys_enter_fchownat/enable
>   # touch /tmp/x
>   # chown sshd /tmp/x
>   # reboot
> 
> On boot up, the dmesg will have:
>  Ring buffer meta [0] is from previous boot!
>  Ring buffer meta [1] is from previous boot!
>  Ring buffer meta [2] is from previous boot!
>  Ring buffer meta [3] is from previous boot!
>  Ring buffer meta [4] commit page not found
>  Ring buffer meta [5] is from previous boot!
>  Ring buffer meta [6] is from previous boot!
>  Ring buffer meta [7] is from previous boot!
> 
> Where the buffer on CPU 4 had a "commit page not found" error and that
> buffer is cleared and reset causing the output to be empty and the data lost.
> 
> When it works correctly, it has:
> 
>   # cat /sys/kernel/tracing/instances/boot_mapped/trace_pipe
>         <...>-1137    [004] .....   998.205323: sys_enter_fchownat: __syscall_nr=0x104 (260) dfd=0xffffff9c (4294967196) filename=(0xffffc90000a0002c) user=0x3e8 (1000) group=0xffffffff (4294967295) flag=0x0 (0
> 
Tested-by: Tasos Sahanidis <tasos@...ossah.com>

Patch resolves the issue on my end. Cheers!