Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1735256
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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