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

[Gui-Dong Han]

On Thu, Mar 5, 2026 at 7:35 PM Oliver Neukum <oneukum@xxxxxxxx> wrote:
>
> On 04.03.26 09:41, Gui-Dong Han wrote:
> > Additionally, the driver relies heavily on set_bit() and test_bit() on
> > desc->flags for synchronization. These bit operations do not provide
> > implicit barriers, which might lead to similar ordering issues.
>
> Hi,
>
> going through the driver it seems to me like all relevant cases
> are covered by the iuspin spinlock. Do you have any concrete suspicions
> or do you generally distrust this style?

Hi Oliver,

Thanks for taking a close look.

I did notice some potential race conditions regarding concurrency
visibility, but I admit I haven't constructed a concrete, harmful
example like the one for ->length and ->ubuf. Analyzing the flags is
less intuitive, and constructing a clear failure path is
time-consuming, so I eventually gave up on building a strict proof for
it.

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.

Thanks.