public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
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 v2 0/2] printk_ringbuffer: don't needlessly wrap data blocks around
Date: Fri, 12 Sep 2025 11:54:59 +0200	[thread overview]
Message-ID: <aMPt8y-8Wazh6ZmO@pathway.suse.cz> (raw)
In-Reply-To: <aMPm8ter0KYBpyoW@pathway.suse.cz>

On Fri 2025-09-12 11:25:09, Petr Mladek wrote:
> On Thu 2025-09-11 18:18:32, John Ogness wrote:
> > On 2025-09-11, Petr Mladek <pmladek@suse.com> wrote:
> > > diff --git a/kernel/printk/printk_ringbuffer_kunit_test.c b/kernel/printk/printk_ringbuffer_kunit_test.c
> > > index 2282348e869a..241f7ef49ac6 100644
> > > --- a/kernel/printk/printk_ringbuffer_kunit_test.c
> > > +++ b/kernel/printk/printk_ringbuffer_kunit_test.c
> > > @@ -56,7 +56,7 @@ struct prbtest_rbdata {
> > >  	char text[] __counted_by(size);
> > >  };
> > >  
> > > -#define MAX_RBDATA_TEXT_SIZE 0x80
> > > +#define MAX_RBDATA_TEXT_SIZE (0x256 - sizeof(struct prbtest_rbdata))
> > 
> > I guess this should be:
> > 
> > #define MAX_RBDATA_TEXT_SIZE (256  - sizeof(struct prbtest_rbdata))
> 
> Great catch!
> 
> But the KUnit test fails even with this change, see below. And I am
> not surprised. The test should work even with larger-than-allowed
> messages. prbtest_writer() should skip then because prb_reserve()
> should fail.
> 
> Here is test result with:
> 
> #define MAX_RBDATA_TEXT_SIZE (256 - sizeof(struct prbtest_rbdata))
> #define MAX_PRB_RECORD_SIZE (sizeof(struct prbtest_rbdata) + MAX_RBDATA_TEXT_SIZE)
> 
> DEFINE_PRINTKRB(test_rb, 4, 4);
> 
> and with this patchset reverted, aka, sources from
> printk/linux.git, branch for-next:
> 
> It is well reproducible. It always fails after reading few records.
> Here are results from few other runs:

And I am not longer able to reproduce it after limiting the size
of the record to 1/4 of the data buffer size. I did it with
the following change:

diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c
index bc811de18316..2f02254705aa 100644
--- a/kernel/printk/printk_ringbuffer.c
+++ b/kernel/printk/printk_ringbuffer.c
@@ -398,8 +398,6 @@ static unsigned int to_blk_size(unsigned int size)
  */
 static bool data_check_size(struct prb_data_ring *data_ring, unsigned int size)
 {
-	struct prb_data_block *db = NULL;
-
 	if (size == 0)
 		return true;
 
@@ -409,7 +407,7 @@ static bool data_check_size(struct prb_data_ring *data_ring, unsigned int size)
 	 * at least the ID of the next block.
 	 */
 	size = to_blk_size(size);
-	if (size > DATA_SIZE(data_ring) - sizeof(db->id))
+	if (size > DATA_SIZE(data_ring) / 4)
 		return false;
 
 	return true;


I guess that there is a race when we need to make all existing records
reusable when making space for the next one.

Another aspect might be the very small amount of descriptors (16).
They are quickly recycled. But it is not a problem after
limiting the size of the record to 1/4.

Note that my test system is using 12 CPUs in KVM.
And it is x86_64.

Best Regards,
Petr

  reply	other threads:[~2025-09-12  9:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05 14:41 [PATCH v2 0/2] printk_ringbuffer: don't needlessly wrap data blocks around Daniil Tatianin
2025-09-05 14:41 ` [PATCH v2 1/2] " Daniil Tatianin
2025-09-05 15:27   ` John Ogness
2025-09-05 15:29     ` Daniil Tatianin
2025-09-05 16:10       ` John Ogness
2025-09-11  8:34         ` Daniil Tatianin
2025-09-11 15:33           ` Petr Mladek
2025-09-05 15:30     ` John Ogness
2025-09-26 14:35   ` Daniil Tatianin
2025-09-26 14:44   ` Petr Mladek
2025-09-26 14:53     ` Daniil Tatianin
2025-10-22 12:46   ` Petr Mladek
2025-09-05 14:41 ` [PATCH v2 2/2] printk_ringbuffer: allow one data block to occupy the entire data ring Daniil Tatianin
2025-09-05 15:27   ` John Ogness
2025-09-11 15:30 ` [PATCH v2 0/2] printk_ringbuffer: don't needlessly wrap data blocks around Petr Mladek
2025-09-11 15:55   ` Petr Mladek
2025-09-11 16:11     ` Petr Mladek
2025-09-11 15:58   ` Petr Mladek
2025-09-11 16:12     ` John Ogness
2025-09-12  9:25       ` Petr Mladek
2025-09-12  9:54         ` Petr Mladek [this message]
2025-09-12 14:49           ` Petr Mladek
2025-09-12 15:15             ` Petr Mladek
2025-09-12 18:43             ` John Ogness
2025-09-13 17:38               ` Daniil Tatianin
2025-09-14  9:23                 ` John Ogness
2025-09-14  9:56                   ` Daniil Tatianin
2025-09-15 15:07                     ` John Ogness
2025-09-15 16:00                       ` Petr Mladek
2025-09-15 16:07                       ` Daniil Tatianin
2025-09-15 15:08               ` Petr Mladek
2025-09-15 15:25                 ` John Ogness

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=aMPt8y-8Wazh6ZmO@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=d-tatianin@yandex-team.ru \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --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