mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: Aleksander Morgado <aleksandermj@chromium.org>,
	oneukum@suse.com, bjorn@mork.no
Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
	linux@roeck-us.net, linux-kernel@vger.kernel.org,
	ejcaruso@chromium.org
Subject: Re: [PATCH] usb: cdc-wdm: close race between read and workqueue
Date: Mon, 15 Apr 2024 10:42:41 +0200	[thread overview]
Message-ID: <6133bcab-ae0f-48f2-b223-2b74082a0552@suse.com> (raw)
In-Reply-To: <385a3519-b45d-48c5-a6fd-a3fdb6bec92f@chromium.org>



On 15.04.24 07:42, Aleksander Morgado wrote:

Hi,

> We are not aware of all the details involved in this patch,

I had gotten bug reports about resubmitting an active URB.

> but we had to revert it in all the different ChromeOS kernel versions where we had it cherry-picked, because it broke the MBIM communication with the Intel XMM based Fibocomm L850 modem. > Other modems shipped in Chromebooks like the QC based Fibocomm FM101 don't seem to be affected.

That is odd.

> Attached is an example output of mbimcli talking directly to the cdc-wdm port (i.e. without ModemManager or the mbim-proxy).

Could you provide a working example, that is with another chipset? And, most important, dmesg for both cases with
the log level set to maximum?

> In the example, we are receiving a bunch of different messages from previous mbimcli runs. Looking at the timestamps, it looks as if we only receive a message right after we have sent one, e.g. after each "open request" we end up receiving responses for requests sent in earlier runs; or something along those lines.

It looks like you are hitting the race later than my bug reporters, which means
that the submission works and we do not overwrite the buffer.
  
> Is this bad behavior of this specific modem chipset, and if so, how can we workaround it? If you need any additional information or help to test new patches, let us know.

Generally losing data is bad, so I cannot readily tell.
Please provide data for the working case.

	Regards
		Oliver


  parent reply	other threads:[~2024-04-15  8:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240314115132.3907-1-oneukum () suse ! com>
2024-04-15  5:42 ` Aleksander Morgado
2024-04-15  6:47   ` Bjørn Mork
2024-04-15  9:06     ` Oliver Neukum
2024-04-15  9:26       ` Bjørn Mork
2024-04-15  9:52         ` Greg KH
2024-04-15 10:07           ` Oliver Neukum
2024-04-15 10:14         ` Oliver Neukum
2024-04-15 10:53           ` Bjørn Mork
2024-04-15 11:08             ` Oliver Neukum
2024-04-15  8:42   ` Oliver Neukum [this message]
2024-04-15 12:08     ` Aleksander Morgado

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=6133bcab-ae0f-48f2-b223-2b74082a0552@suse.com \
    --to=oneukum@suse.com \
    --cc=aleksandermj@chromium.org \
    --cc=bjorn@mork.no \
    --cc=ejcaruso@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®