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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <07b88f71-5b77-4c16-bd55-3f5e3812c93e@suse.com>
Date: Thu, 4 Jul 2024 13:03:47 +0200
From: Petr Pavlu <petr.pavlu@...e.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ring-buffer: Limit time with disabled interrupts in
 rb_check_pages()

On 7/3/24 23:44, Steven Rostedt wrote:
> On Wed,  3 Jul 2024 09:53:14 +0200
> Petr Pavlu <petr.pavlu@...e.com> wrote:
> 
>> The function rb_check_pages() validates the integrity of a specified
>> per-CPU tracing ring buffer. It does so by traversing the underlying
>> linked list and checking its next and prev links.
>>
>> To guarantee that the list isn't modified during the check, a caller
>> typically needs to take cpu_buffer->reader_lock. This prevents the check
>> from running concurrently, for example, with a potential reader which
>> can make the list temporarily inconsistent when swapping its old reader
>> page into the buffer.
>>
>> A problem with this approach is that the time when interrupts are
>> disabled is non-deterministic, dependent on the ring buffer size. This
>> particularly affects PREEMPT_RT because the reader_lock is a raw
>> spinlock which doesn't become sleepable on PREEMPT_RT kernels.
>>
>> Modify the check so it still attempts to traverse the entire list, but
>> gives up the reader_lock between checking individual pages. Introduce
>> for this purpose a new variable ring_buffer_per_cpu.pages_era which is
> 
> I'm dumb. What's an "era"?

I meant it as a calendar era or epoch. The idea was to hint this is
a number that identifies some structural state of the pages list. Maybe
pages_gen ("generation") or another name would be better?

-- Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ