Re: Question about desc_push_tail in Linux printk ringbuffer

[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