All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	robert.hodaszi@digi.com, kees@kernel.org,
	linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Jia-Ju Bai <baijiaju1990@gmail.com>
Subject: Re: [BUG] usb: cdc-wdm: Missing barriers in ad-hoc lockless buffer
Date: Fri, 6 Mar 2026 10:25:07 +0100	[thread overview]
Message-ID: <6c70210c-e437-420e-a1ee-fab44622aea3@suse.com> (raw)
In-Reply-To: <CALbr=LZVqqYmV_1qZvh2-5pizrkDE=kqUW_Yb6GWPu65gVFnLg@mail.gmail.com>



On 05.03.26 14:26, Gui-Dong Han wrote:

Hi,

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

Nevertheless, you've found the issue, hence I will ask you :-)

Is that something we can depend on or is that just how it works
on the architectures we are currently running on? If I go to the effort
of checking for reordering effects, I want to do it right in all cases.
   
> 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.

Yes. Hence I was looking. The results of a completed IO can be

a) data
b) an error
c) a buffer overflow

thus there must be ordering between recording any of these results
and changing WDM_READ, right?

> 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 :)

I agree. The issue is that lockless IO is also error handling, not
just the buffer.

	Regards
		Oliver


  reply	other threads:[~2026-03-06  9:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04  8:41 [BUG] usb: cdc-wdm: Missing barriers in ad-hoc lockless buffer Gui-Dong Han
2026-03-04  9:15 ` Greg KH
2026-03-05 11:35 ` Oliver Neukum
2026-03-05 12:28   ` Gui-Dong Han
2026-03-05 12:44     ` Oliver Neukum
2026-03-05 13:26       ` Gui-Dong Han
2026-03-06  9:25         ` Oliver Neukum [this message]
2026-03-06 10:36           ` Gui-Dong Han

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c70210c-e437-420e-a1ee-fab44622aea3@suse.com \
    --to=oneukum@suse.com \
    --cc=baijiaju1990@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanguidong02@gmail.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robert.hodaszi@digi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.