Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1499662
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() |
| Date | 2016-10-12 15:20 +0200 |
| Message-ID | <srrBT-4SP-11@gated-at.bofh.it> (permalink) |
| References | <sqQ9k-6f1-17@gated-at.bofh.it> <sqZvX-3En-1@gated-at.bofh.it> <sraro-1SH-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, 11 Oct 2016, Andreas Mohr wrote: > On Tue, Oct 11, 2016 at 09:14:38AM +0200, Thomas Gleixner wrote: > > On Mon, 10 Oct 2016, Douglas Anderson wrote: > > > Users of usleep_range() expect that it will _never_ return in less time > > > than the minimum passed parameter. However, nothing in any of the code > > > ensures this. Specifically: > > > > There is no such guarantee for that interface and never has been, so how > > did you make sure that none of the existing users is relying on this? > > > > You can't just can't just declare that all all of the users expect that and > > be done with it. > > Hmm, somehow I don't manage to follow these thoughts. > > https://www.kernel.org/doc/htmldocs/device-drivers/API-usleep-range.html > (as a hopefully sufficiently authoritative source of documentation) > clearly specifies min to be > "Minimum time in usecs to sleep" > , which is what one would expect a two-param interface here to be > (minimum-maximum), > i.e. what would be the *natural* protocol I'd think. > > Also, [finally...] starting to enforce the minimum time > is an additional *constraint* on the protocol, > i.e. it's not at all like we are getting more *liberal* here > (since usually getting more liberal in certain protocols > is what will cause trouble, I'd think). > > Not to mention that > desiring a delay in processing most certainly is > what caused users of this API to decide to invoke it in the first place > (else they would just have chosen to carry on with delay-less processing > and be done with it). > And those users then surely wouldn't want to experience a behaviour > where the delay may be ended at any time, > however short that may end up being. I'm well aware what Doug wants to do and I'm not saying that this is wrong, but I'm not going to look at all usleep() usage sites to make sure none is relying on such a behaviour and gets surprised by the change, The point is that we had cases over and over where stuff was depending on implementation bugs which made the buggy behaviour into an expected behaviour. I'm not saying that this is the case here, but it's not my duty to make sure it isn't. So the very minimum I need in the changelog is some mentioning that the author at least tried to verify that this is not going to break the world and some more. That's what I meant by: You can't just can't just declare that all all of the users expect that and be done with it. Thanks, tglx
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Douglas Anderson <dianders@chromium.org> - 2016-10-10 23:20 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-11 00:40 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Thomas Gleixner <tglx@linutronix.de> - 2016-10-11 09:20 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-11 18:40 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Mark Brown <broonie@kernel.org> - 2016-10-12 11:30 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Andreas Mohr <andi@lisas.de> - 2016-10-11 21:00 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Thomas Gleixner <tglx@linutronix.de> - 2016-10-12 15:20 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-12 19:40 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Heiko Stuebner <heiko@sntech.de> - 2016-10-11 22:40 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Brian Norris <briannorris@chromium.org> - 2016-10-11 21:00 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Andreas Mohr <andi@lisas.de> - 2016-10-11 21:50 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-11 22:10 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Andreas Mohr <andi@lisas.de> - 2016-10-11 22:50 +0200
Re: [v2] timers: Fix usleep_range() in the context of wake_up_process() Guenter Roeck <linux@roeck-us.net> - 2016-10-12 18:10 +0200
Re: [v2] timers: Fix usleep_range() in the context of wake_up_process() Guenter Roeck <linux@roeck-us.net> - 2016-10-12 19:00 +0200
Re: [v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-12 19:00 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Daniel Kurtz <djkurtz@chromium.org> - 2016-10-18 15:50 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Doug Anderson <dianders@chromium.org> - 2016-10-18 22:30 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Daniel Kurtz <djkurtz@chromium.org> - 2016-10-20 11:00 +0200
Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Thomas Gleixner <tglx@linutronix.de> - 2016-10-20 12:00 +0200
csiph-web