Re: [PATCH v2 1/2] printk_ringbuffer: don't needlessly wrap data blocks around

[Petr Mladek]

On Thu 2025-09-11 11:34:54, Daniil Tatianin wrote:
> 
> On 9/5/25 7:10 PM, John Ogness wrote:
> > On 2025-09-05, Daniil Tatianin <d-tatianin@xxxxxxxxxxxxxx> wrote:
> > > On 9/5/25 6:27 PM, John Ogness wrote:
> > > > On 2025-09-05, Daniil Tatianin <d-tatianin@xxxxxxxxxxxxxx> wrote:
> > > > > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c
> > > > > index d9fb053cff67..99989a9ce4b4 100644
> > > > > --- a/kernel/printk/printk_ringbuffer.c
> > > > > +++ b/kernel/printk/printk_ringbuffer.c
> > > > > @@ -1234,14 +1245,14 @@ static const char *get_data(struct prb_data_ring *data_ring,
> > > > >    	}
> > > > >    	/* Regular data block: @begin less than @next and in same wrap. */
> > > > > -	if (DATA_WRAPS(data_ring, blk_lpos->begin) == DATA_WRAPS(data_ring, blk_lpos->next) &&
> > > > > +	if (!is_blk_wrapped(data_ring, blk_lpos->begin, blk_lpos->next) &&
> > > > >    	    blk_lpos->begin < blk_lpos->next) {
> > > > >    		db = to_block(data_ring, blk_lpos->begin);
> > > > >    		*data_size = blk_lpos->next - blk_lpos->begin;
> > > > >    	/* Wrapping data block: @begin is one wrap behind @next. */
> > > > > -	} else if (DATA_WRAPS(data_ring, blk_lpos->begin + DATA_SIZE(data_ring)) ==
> > > > > -		   DATA_WRAPS(data_ring, blk_lpos->next)) {
> > > > > +	} else if (!is_blk_wrapped(data_ring,
> > > > > +		   blk_lpos->begin + DATA_SIZE(data_ring), blk_lpos->next)) {
> > > > It would look nicer if the arguments of the function were indented to
> > > > the function parenthesis:
> > > > 
> > > > 	} else if (!is_blk_wrapped(data_ring, blk_lpos->begin +
> > > > 				   DATA_SIZE(data_ring), blk_lpos->next)) {
> > > Would you like me to resend with this addressed?
> > Knowing Petr, I would say "yes". :-)
> > 
> > But wait for Petr's response before sending anything.
> 
> Friendly ping for Petr :)

I am sorry for the delay. I actually was going to look at it today.
But to make expectations. I am a bit overloaded by other tasks.
And frankly, this patchset is not a big priority. It allows
to use 4 unused bytes which is a negligible win. And it stretches
the limits which might open a hole which was closed by chance before.

Best Regards,
Petr