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@xxxxxxxxxxxxx>:
>
> Hi Alexandre,
>
> On 2026-09-05, Alexandre Boissière <edu.alexandre.boissiere@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxx
>
> Please follow-up with a question if it is still not clear.
>
> John