Messages in this thread | | | From | Jos Vos <> | Subject | Re: Bug in IP accounting explained | Date | 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
| |