[<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