Question about desc_push_tail in Linux printk ringbuffer

Question about desc_push_tail in Linux printk ringbuffer

[Alexandre Boissière]

Hello,

I have recently been trying to understand how the Linux printk ring
buffer works.

However, despite it being heavily commented, I cannot understand the
logic behind the condition in the desc_miss case at the beginning of
the desc_push_tail method (lines 716-719 in commit b6cf8b3, lines
801-804 in the latest commit bf56987c).

From what the comment says, it is meant to guard against another
writer currently reserving the descriptor. My understanding is that
this can only happen if there are concurrent calls to desc_reserve.

I have been trying to figure out a scenario that would make this
condition evaluate to true, but to no avail.

The difficulty I am facing is that desc_push_tail is called with the
value of the current tail (or the new head one wrap backwards), so for
this condition to hold, the ID of the desired descriptor would need to
be two wraps behind the new head?

However, given the way the ringbuffer works, and if there is another
writer, it should either contain the value of the tail if the other
writer has done the head CAS in desc_reserve but hasn't reached the
state_var CAS before the return statement; or the value of the tail
one wrap forward (which is equal to the new head) if the other writer
has finished both CAS.

None of these two cases yield a descriptor ID that is two wraps behind
the new head, hence my inquiry about this topic.

Is there a scenario that would make this condition evaluate to true
that I am missing?

I hope my explanation is understandable enough.

Thank you for your time, and best regards,
Alexandre Boissiere

Re: Question about desc_push_tail in Linux printk ringbuffer

[John Ogness]

Hi Alexandre,

On 2026-09-05, Alexandre Boissière <edu.alexandre.boissiere@gmail.com> wrote:
> I have recently been trying to understand how the Linux printk ring
> buffer works.
>
> However, despite it being heavily commented, I cannot understand the
> logic behind the condition in the desc_miss case at the beginning of
> the desc_push_tail method (lines 716-719 in commit b6cf8b3, lines
> 801-804 in the latest commit bf56987c).

We originally did not have this special case. Petr discovered the
need. You can read our dialogue when we realized we needed this.

https://lore.kernel.org/lkml/20190709090609.shx7j2mst7wlkbqm@pathway.suse.cz

It is the comments related to "two-wraps-old".

> From what the comment says, it is meant to guard against another
> writer currently reserving the descriptor. My understanding is that
> this can only happen if there are concurrent calls to desc_reserve.
>
> I have been trying to figure out a scenario that would make this
> condition evaluate to true, but to no avail.
>
> The difficulty I am facing is that desc_push_tail is called with the
> value of the current tail (or the new head one wrap backwards), so for
> this condition to hold, the ID of the desired descriptor would need to
> be two wraps behind the new head?
>
> However, given the way the ringbuffer works, and if there is another
> writer, it should either contain the value of the tail if the other
> writer has done the head CAS in desc_reserve but hasn't reached the
> state_var CAS before the return statement; or the value of the tail
> one wrap forward (which is equal to the new head) if the other writer
> has finished both CAS.
>
> None of these two cases yield a descriptor ID that is two wraps behind
> the new head, hence my inquiry about this topic.
>
> Is there a scenario that would make this condition evaluate to true
> that I am missing?

In Petr's follow-up message he goes through a scenario:

https://lore.kernel.org/lkml/20190709115814.5nykd6yroae7wmxw@pathway.suse.cz

Please follow-up with a question if it is still not clear.

John

Re: Question about desc_push_tail in Linux printk ringbuffer

[Alexandre Boissiere]

Hello John,

Thank you very much for the links.

The scenario in Petr's follow-up clarified it well and I understand now.

Best regards,

Alexandre


Am Mo., 7. Sept. 2026 um 09:55 Uhr schrieb John Ogness
<john.ogness@linutronix.de>:
>
> Hi Alexandre,
>
> On 2026-09-05, Alexandre Boissière <edu.alexandre.boissiere@gmail.com> wrote:
> > I have recently been trying to understand how the Linux printk ring
> > buffer works.
> >
> > However, despite it being heavily commented, I cannot understand the
> > logic behind the condition in the desc_miss case at the beginning of
> > the desc_push_tail method (lines 716-719 in commit b6cf8b3, lines
> > 801-804 in the latest commit bf56987c).
>
> We originally did not have this special case. Petr discovered the
> need. You can read our dialogue when we realized we needed this.
>
> https://lore.kernel.org/lkml/20190709090609.shx7j2mst7wlkbqm@pathway.suse.cz
>
> It is the comments related to "two-wraps-old".
>
> > From what the comment says, it is meant to guard against another
> > writer currently reserving the descriptor. My understanding is that
> > this can only happen if there are concurrent calls to desc_reserve.
> >
> > I have been trying to figure out a scenario that would make this
> > condition evaluate to true, but to no avail.
> >
> > The difficulty I am facing is that desc_push_tail is called with the
> > value of the current tail (or the new head one wrap backwards), so for
> > this condition to hold, the ID of the desired descriptor would need to
> > be two wraps behind the new head?
> >
> > However, given the way the ringbuffer works, and if there is another
> > writer, it should either contain the value of the tail if the other
> > writer has done the head CAS in desc_reserve but hasn't reached the
> > state_var CAS before the return statement; or the value of the tail
> > one wrap forward (which is equal to the new head) if the other writer
> > has finished both CAS.
> >
> > None of these two cases yield a descriptor ID that is two wraps behind
> > the new head, hence my inquiry about this topic.
> >
> > Is there a scenario that would make this condition evaluate to true
> > that I am missing?
>
> In Petr's follow-up message he goes through a scenario:
>
> https://lore.kernel.org/lkml/20190709115814.5nykd6yroae7wmxw@pathway.suse.cz
>
> Please follow-up with a question if it is still not clear.
>
> John