Re: [PATCH] push rounding up of relative request to schedule_timeout()

[Roman Zippel]

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