Messages in this thread | | | Date | Thu, 4 Aug 2005 11:38:33 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [PATCH] push rounding up of relative request to schedule_timeout() |
| |
Hi,
Andrew, please drop this patch. Nish, please stop fucking around with kernel APIs.
On Wed, 3 Aug 2005, Nishanth Aravamudan wrote:
> > The "jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1)" case (when the > > process is immediately woken up again) makes the caller suspectible to > > timeout manipulations and requires constant reauditing, that no caller > > gets it wrong, so it's better to avoid this error source completely.
Nish, did you read this? Is my English this bad?
> --- 2.6.13-rc5/kernel/timer.c 2005-08-01 12:31:53.000000000 -0700 > +++ 2.6.13-rc5-dev/kernel/timer.c 2005-08-03 17:30:10.000000000 -0700 > @@ -1134,7 +1134,7 @@ fastcall signed long __sched schedule_ti > } > } > > - expire = timeout + jiffies; > + expire = timeout + jiffies + 1; > > init_timer(&timer); > timer.expires = expire;
And a little later it does:
timeout = expire - jiffies;
which means callers can get back a larger timeout. Nish, did you check and fix _all_ users? I can easily find a number of users which immediately use the return value as next timeout. There are _a_lot_ of schedule_timeout(1) for small busy loops, these are asking for "please schedule until next tick". Did you check that these are still ok? schedule_timeout() is arguably a broken API, but can we please _first_ come up with a plan to fix this, before we break even more?
bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |