public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Daniil Tatianin <d-tatianin@yandex-team.ru>,
	Petr Mladek <pmladek@suse.com>
Cc: Daniil Tatianin <d-tatianin@yandex-team.ru>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v1] printk_ringbuffer: don't needlessly wrap data blocks around
Date: Thu, 04 Sep 2025 09:39:44 +0206	[thread overview]
Message-ID: <84v7lyu0x3.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20250903001008.6720-1-d-tatianin@yandex-team.ru>

On 2025-09-03, Daniil Tatianin <d-tatianin@yandex-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

  reply	other threads:[~2025-09-04  7:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03  0:10 [PATCH v1] printk_ringbuffer: don't needlessly wrap data blocks around Daniil Tatianin
2025-09-04  7:33 ` John Ogness [this message]
2025-09-04 13:58 ` John Ogness
2025-09-04 16:33   ` Petr Mladek
2025-09-04 16:50     ` Daniil Tatianin
2025-09-05  9:13     ` John Ogness
2025-09-05 10:47       ` Petr Mladek
2025-09-04 14:30 ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84v7lyu0x3.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=d-tatianin@yandex-team.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox