On Thu, Jul 17, 2008 at 11:42 PM, Ingo Molnar <mingo@elte.hu> wrote:1. Notice the range. It's just a single byte. 2. Notice the value. It's just a ++. Probably a stray increment of a uint8_t somewhere on a freed object? The offset from the beginning of the object is 0xf658ae9c - 0xf658ae00 = 0x9c. How big is a struct sk_buff? Hm.. it is in fact quite big. Now what member has offset 0x9c? Seems to depend on your config. Is there any way you can figure it out, Ingo? I'll try it with your config too. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
git: | |
| Gerrit Renker | [PATCH 28/37] dccp: Integration of dynamic feature activation - part 3 (client side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Tantilov, Emil S | WARNING: at include/net/sock.h:417 udp_lib_unhash |
