Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1735256

Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()

From Doug Anderson <dianders@chromium.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent()
Date 2017-09-19 23:00 +0200
Message-ID <urxMB-1ME-3@gated-at.bofh.it> (permalink)
References <urtpD-7FJ-17@gated-at.bofh.it> <urtpE-7FJ-27@gated-at.bofh.it> <urxCW-1Jf-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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
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...

-Doug

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may have been dropped" Douglas Anderson <dianders@chromium.org> - 2017-09-19 18:20 +0200
  [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent() Douglas Anderson <dianders@chromium.org> - 2017-09-19 18:20 +0200
    Re: [RFC PATCH 2/3] usbnet: Avoid potential races in  usbnet_deferred_kevent() Oliver Neukum <oneukum@suse.com> - 2017-09-19 22:50 +0200
      Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent() Doug Anderson <dianders@chromium.org> - 2017-09-19 23:00 +0200
        Re: [RFC PATCH 2/3] usbnet: Avoid potential races in  usbnet_deferred_kevent() Oliver Neukum <oneukum@suse.com> - 2017-09-20 10:30 +0200
      Re: [RFC PATCH 2/3] usbnet: Avoid potential races in usbnet_deferred_kevent() Guenter Roeck <groeck@google.com> - 2017-09-19 23:00 +0200
        Re: [RFC PATCH 2/3] usbnet: Avoid potential races in  usbnet_deferred_kevent() Oliver Neukum <oneukum@suse.com> - 2017-09-20 10:30 +0200
  [RFC PATCH 3/3] usbnet: Fix memory leak when rx_submit() fails Douglas Anderson <dianders@chromium.org> - 2017-09-19 18:20 +0200
    Re: [RFC PATCH 3/3] usbnet: Fix memory leak when rx_submit() fails Bjørn Mork <bjorn@mork.no> - 2017-09-19 19:50 +0200
  Re: [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may  have been dropped" Guenter Roeck <groeck@google.com> - 2017-09-19 18:50 +0200
  Re: [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may have been dropped" Bjørn Mork <bjorn@mork.no> - 2017-09-19 19:50 +0200
  Re: [RFC PATCH 1/3] usbnet: Get rid of spammy usbnet "kevent X may  have been dropped" Oliver Neukum <oneukum@suse.com> - 2017-09-19 22:40 +0200

csiph-web