[lkml]   [1997]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bug in IP accounting explained
    > 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 <>
    -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
    -- Amsterdam, The Netherlands | Fax: +31 20 6948204

     \ /
      Last update: 2005-03-22 13:39    [W:0.024 / U:0.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site