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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
