From: Oliver Neukum <oneukum@suse.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>,
Grant Grundler <grundler@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()
Date: Wed, 20 Sep 2017 10:25:46 +0200 [thread overview]
Message-ID: <1505895946.27967.3.camel@suse.com> (raw)
In-Reply-To: <CAD=FV=WJOrpEqpUGA3EL5BMQTMN9NVgekd7qBX+u=gX90eRGyA@mail.gmail.com>
Am Dienstag, den 19.09.2017, 13:53 -0700 schrieb Doug Anderson:
> Hi,
>
> On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum <oneukum@suse.com> wrote:
> >
> > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
> > >
> > > In general when you've got a flag communicating that "something needs
> > > to be done" you want to clear that flag _before_ doing the task. If
> > > you clear the flag _after_ doing the task you end up with the risk
> > > that this will happen:
> > >
> > > 1. Requester sets flag saying task A needs to be done.
> > > 2. Worker comes and stars doing task A.
> > > 3. Worker finishes task A but hasn't yet cleared the flag.
> > > 4. Requester wants to set flag saying task A needs to be done again.
> > > 5. Worker clears the flag without doing anything.
> > >
> > > Let's make the usbnet codebase consistently clear the flag _before_ it
> > > does the requested work. That way if there's another request to do
> > > the work while the work is already in progress it won't be lost.
> > >
> > > NOTES:
> > > - No known bugs are fixed by this; it's just found by code inspection.
> >
> > Hi,
> >
> > unfortunately the patch is wrong. The flags must be cleared only
> > in case the handler is successful. That is not guaranteed.
> >
> > Regards
> > Oliver
> >
> > NACK
>
> OK, thanks for reviewing! I definitely wasn't super confident about
> the patch (hence the RFC).
>
> Do you think that the races I identified are possible to hit? In
As far as I can tell, we are safe, but you are right to say that the
driver is not quite clean at that point.
> other words: should I try to rework the patch somehow or just drop it?
> Originally I had the patch setting the flags back to true in the
> failure cases, but then I convinced myself that wasn't needed. I can
> certainly go back and try it that way...
Setting the flags again in the error case would certainly be an
improvement. I'd be happy with a patch doing that.
Regards
Oliver
next prev parent reply other threads:[~2017-09-20 8:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 16:15 [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may have been dropped" Douglas Anderson
2017-09-19 16:15 ` [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent() Douglas Anderson
2017-09-19 20:37 ` Oliver Neukum
2017-09-19 20:51 ` Guenter Roeck
2017-09-20 8:23 ` Oliver Neukum
2017-09-19 20:53 ` Doug Anderson
2017-09-20 8:25 ` Oliver Neukum [this message]
2017-09-19 16:15 ` [RFC PATCH 3/3] usbnet: Fix memory leak when rx_submit() fails Douglas Anderson
2017-09-19 17:41 ` Bjørn Mork
2017-09-19 16:43 ` [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may have been dropped" Guenter Roeck
2017-09-19 17:45 ` Bjørn Mork
2017-09-19 20:36 ` Oliver Neukum
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=1505895946.27967.3.camel@suse.com \
--to=oneukum@suse.com \
--cc=dianders@chromium.org \
--cc=groeck@chromium.org \
--cc=grundler@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.