Re: [BUG] usb: cdc-wdm: Missing barriers in ad-hoc lockless buffer

[Gui-Dong Han]

On Thu, Mar 5, 2026 at 8:44 PM Oliver Neukum <oneukum@xxxxxxxx> wrote:
>
>
>
> On 05.03.26 13:28, Gui-Dong Han wrote:
>
> > Specifically, wdm_read() accesses ->length and then ->flags, often
> > without holding ->iuspin. Similarly, wdm_in_callback() involves
> > multiple accesses to both.
> >
> > I am indeed nervous about this pattern. Without barriers, changes to
> > these associated fields made on one CPU might be observed in a
> > completely different order on another CPU.
>
> OK, I rechecked. And indeed it seems to me like setting WDM_OVERFLOW
> and WDM_READ could be reordered with respect to each other in
> wdm_in_callback() and that must not happen.
> What do you think?

Hi Oliver,

Based on my shallow understanding, reordering issues typically happen
between different memory addresses, not within the same one.

For a single variable, hardware cache coherence guarantees the
modification order. For example, if a CPU writes 1, 2, and 4 to int a,
other CPUs will definitely observe the changes in that exact 1-2-4
sequence. So set_bit() operations on the same desc->flags should be
safe from being observed out-of-order.

The real danger of weak memory architectures lies in accessing
associated variables. For instance, if we write 1 to int a and then 2
to int b, another CPU might observe b == 2 before a == 1. This is
exactly the situation I pointed out in my original report regarding
the lack of barriers between desc->ubuf and desc->length.

Honestly, lockless algorithm design is incredibly hard, which is why
drivers should probably just rely on well-tested libraries instead of
rolling their own. I am definitely no expert in this dark art, just
know enough to be dangerous :)

Thanks.