From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: EJ Hsu <ejh@nvidia.com>, Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"balbi@kernel.org" <balbi@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
WK Tsai <wtsai@nvidia.com>
Subject: Re: [PATCH V3] usb: gadget: storage: Remove warning message
Date: Sat, 06 Jul 2019 08:09:23 +1000 [thread overview]
Message-ID: <b93cdcb5f1b58621419c49eba952e092578753c3.camel@kernel.crashing.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1907051024420.1606-100000@iolanthe.rowland.org>
On Fri, 2019-07-05 at 10:30 -0400, Alan Stern wrote:
> I haven't looked at the new patches yet.
>
> Still, what I originally had in mind for this situation was that the
> _last_ event should always take precedence. This goes against the idea
> of having separate FSG_STATE_* levels for disconnect and config-change,
> because the driver assumes that higher levels should override lower
> levels.
Right, this is what my new tentative patch does. The main caveat is to
ensure that if that last event arrives after the previous one was
"dequeued" by the thread but before it was *processed*, then we don't
clobber it's argument (new_fsg) and thus end up processing both events
each with the appropriate corresponding value of new_fsg.
This is the root of the bug in fact: When the second event occurs in
that window, we end up processing twice, as expected, but potentially
using twice the *new* new_fsg value.
> Also, if the thread has already started processing one of these events
> when another one occurs, the new exception should cause the thread to
> restart the handler and thus take care of the new event. And yes,
> there should be enough locking to ensure that nothing gets stomped on
> except in situations where it won't matter.
>
> That's how I think this should all work, and it doesn't look like we
> really need a queue to do it properly.
Yes, I agree. That's what the patch I posted last night aims at, I need
to test it today.
Cheers,
Ben.
next prev parent reply other threads:[~2019-07-05 22:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 11:02 [PATCH V3] usb: gadget: storage: Remove warning message EJ Hsu
2019-05-10 14:29 ` Alan Stern
2019-07-02 1:58 ` Thinh Nguyen
2019-07-02 14:10 ` Alan Stern
[not found] ` <CY4PR1201MB0037C93EC7F81A394008C4CCAAF80@CY4PR1201MB0037.namprd12.prod.outlook.com>
2019-07-02 18:06 ` Thinh Nguyen
2019-07-03 11:20 ` EJ Hsu
2019-07-04 8:39 ` EJ Hsu
2019-07-04 16:06 ` Alan Stern
2019-07-05 10:49 ` EJ Hsu
2019-07-05 12:28 ` Benjamin Herrenschmidt
2019-07-05 14:30 ` Alan Stern
2019-07-05 22:09 ` Benjamin Herrenschmidt [this message]
2019-07-05 12:34 ` Benjamin Herrenschmidt
2019-07-05 13:13 ` Benjamin Herrenschmidt
2019-07-05 18:28 ` Alan Stern
2019-07-05 22:11 ` Benjamin Herrenschmidt
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=b93cdcb5f1b58621419c49eba952e092578753c3.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=balbi@kernel.org \
--cc=ejh@nvidia.com \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=wtsai@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox