linux-kernel - Re: [PATCH v1] printk_ringbuffer: don't needlessly wrap data blocks around

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: <84v7lyu0x3.fsf@jogness.linutronix.de>
Date: Thu, 04 Sep 2025 09:39:44 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Daniil Tatianin <d-tatianin@...dex-team.ru>, Petr Mladek <pmladek@...e.com>
Cc: Daniil Tatianin <d-tatianin@...dex-team.ru>,
 linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, Sergey
 Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH v1] printk_ringbuffer: don't needlessly wrap data blocks
 around

On 2025-09-03, Daniil Tatianin <d-tatianin@...dex-team.ru> wrote:
> Previously, data blocks that perfectly fit the data ring buffer would
> get wrapped around to the beginning for no reason since the calculated
> offset of the next data block would belong to the next wrap. Since this
> offset is not actually part of the data block, but rather the offset of
> where the next data block is going to start, there is no reason to
> include it when deciding whether the current block fits the buffer.

FYI, I am taking a look at this. We need to be really careful not to
introduce any subtle bugs.

As an example, data_check_size() makes sure there is always room for the
trailing "next ID". But with your patch, that check is
overconservative. For that particular case it really isn't an issue, it
just means you would not be able to have a record the fills the full
ringbuffer. But my point is that there may be parts of the code that
assume there is always a trailing "next ID" (since so far that has
always been true).

I just want to be careful in my review of it. So please be patient.

John