On Sun, Jan 06, 2008 at 11:30:48AM +0100, Torsten Kaiser wrote: ...Of course it looks like using the same data, but it seems there is no reason to think it needs the same time: e.g. some timer or workqueue could retrigger after it's supposed to be killed. Any additional debugging/poisonning might help to see it earlier, so this should be safer for your system, but, most probably this would show data from the damaged side, so not necessarily very helpful. We are not even sure skbuffs were directly affected by this or they were incorrectly freed because of other structures beeing damaged? IMHO, e.g. starting your system with limited memory should cause faster memory reclaiming, and thus more often triggering of these bugs, but of course I can be wrong. Jarek P. --
| Faik Uygur | Re: Linux 2.6.21-rc1 |
| pageexec | Re: [stable] Linux 2.6.25.10 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
