Re: Bug in IP accounting explained
Jos Vos (jos@xos.nl)
Mon, 02 Jun 1997 18:39:35 +0200
> When the next call to ip_chain_procinfo comes in, the only state that's
> passed is in the file offset. Hence it has to rewalk the list,
> converting all the entries again to get up to the point where it left
> off last time. The problem is that the linked list elements copied out
> the first time may have changed, and the new conversion by sprintf() may
> not be the same length as before. But ip_chain_procinfo returns the
> starting buffer position corresponding to the file offset, and so may
> chop off part of the new data being returned.
>
> There's an easy cheesy fix, which is just to make all of the sprintf()
> format conversions have a fixed width, so that the converted length
> can't change between calls. The right way to fix it would be to make
> all the returned lines the same length, then divide the offset by the
> length to calculate how many list nodes to skip over before starting the
> new conversion.
>
> This same problem could apply to any /proc entry that has to walk a
> linked list where the length of the data converted may change between
> calls. If an entry required many calls to complete, it would result in
> something on the order of N**2 sprintf conversions being done (and with
> interrupts turned off in each call.)
The problem with the /proc entries is known for long, I think (when will
this change, please...?), and this was the reason that we _tried_ to make
all entries having the same length. Unfortunately, as Alan and some others
already explained, the %-9lu for printf'ing the counters is one char too
small, so changing this to %-10lu will solve the problem. Some people
already reported that they haven't had any problems after changing this.
I suggest to just make this small change for 2.0.31. Maybe in the future
we can change to code a bit more, but I don't want to introduce possible
new bugs in 2.0.31 (we first have to solve the bugs 2.0.30 introduced :-().
In fact, I still hope that the /proc code will be "fixed" (e.g., adding
some "streaming" mechanism or so) so that we can simplify the code (and
make it more efficient - the current code is very inefficient when _long_
lists of rules exist.
--
-- Jos Vos <jos@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204