Bug when calculating ticks_per_usec

[Thomas Graf]

On Thu, Jan 14, 2010 at 06:27:12PM +0100, Jose Ignacio Naranjo wrote:
> Hi list,
> 
> I've noticed a wrong behavior when setting up some delays in a netem
> qdisc.  I will try to make the things easier for the reader describing
> the calls path.
> 
> To set up a delay (or jitter...) I use 'rtnl_netem_set_delay' which
> requires an int parameter that tells the delay in micro seconds. Inside
> this func, the delay is set up with the help of 'nl_us2ticks', which is
> just an arithmetic operation (us * ticks_per_usec), where us is the
> input parameter and ticks_per_usec is a global variable initialized in
> 'get_psched_settings'. And here is the problem:
> 
> If this variable is going to be calculated using '/proc/net/psched', I
> think the file scan is not done properly.
> 
> I don't understand what the meaning of the asterisk is here:
> 
> int r = fscanf(fd, "%08x%08x%08x%*08x", &tick, &us, &nom);
> if (4 == r && nom == 1000000 && !got_tick)
> 	ticks_per_usec = (double)tick/(double)us;
> 
> The execution path never gets in the if statement, because r is always
> 3, and if the fourth parameter is read (avoiding the asterisk), there is
> no variable to store it in, so it comes a segv. In my opinion we can get
> rid of the if statement, because I think the proc psched file has always
> a fixed format of 4 parameters, and 'nom' is always 1000000
> (http://lxr.linux.no/#linux+v2.6.32/net/sched/sch_api.c#L1678).

This code was originally taken from iproute2 and probably used to work once.

I applied your patch, thanks very much.