Bug when calculating ticks_per_usec

[Jose Ignacio Naranjo]

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).

Find attached a patch I did, if I am correct.

Regards,
JI
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Fix-a-bug-when-calculating-ticks_per_usec.patch
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20100114/d0f3b791/attachment.el>