But a sister machine running the same 2.0.33 kernel as before (compiled
with 2.8.0 to boot) is not leaking. Its net buffer use is up to 32
after two and a half days uptime. That is more than 1 but less than
20000. It is sitting next to the affected server, just not exporting
its files systems by NFS like the server is.
"A month of sundays ago Alan Cox wrote:"
>
> > bridging? I just tried brcfg -enable, with slightly _disastrous_ results
> > for the ciped tunnels running at the time. Hard to tell what broke first.
> > Bits of e2fs also went strange.
>
> 2.0.34 fixed a range of memory leaks as well as nestea2 attacks.
So I take it that 2.0.24 fixed this leak in particular. I would be
interested in locating the precise fix, as I would like to port it back
to earlier kernels. My feeling is that this leak was introduced by the
teardrop fix, and is activated by exporting nfs file systems on a bridge
configured system without bridging enabled. It must be a section of code
inside #ifdef CONFIG_BRIDGE ... #endif? I'll look for it.
As I wrote above - trying the trick of activating the bridge to see if
that would stop the leak took both my ciped tunnels out of action,
seemingly irretreviably. Is this problem knows (should I copy to
olaf?).
BTW - I fully intend to recompile with 2.8.0 and exclude the
possibility of the bug being introduced from there. I don't like this
hate mail campaign against 2.8.*, which is a perfectly nice compiler,
at least as good ass solaris cc and hpux's one (whatever it is,
nowadays). I've found more bugs in the latter two than I ever have in
gcc 2.8.0.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu