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

Petr Mladek
2025-09-11T15:33:17Z

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@yandex-team.ru> wrote:
> > > On 9/5/25 6:27 PM, John Ogness wrote:
> > > > On 2025-09-05, Daniil Tatianin <d-tatianin@yandex-team.ru> 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