> On Fri, 7 May 1999, Roy Stogner wrote:
>
> > eax: c02bde3c ebx: 00000001 ecx: c02bde30 edx: 00000000
> > esi: c02bddc0 edi: c1fda000 ebp: c0200008 esp: c020bf28
> [...]
> > Code: c016570b <pfifo_fast_dequeue+1b/50> 00000000 <_EIP>: <===
> > Code: c016570b <pfifo_fast_dequeue+1b/50> 0: 89 4a 04 movl %ecx,0x4(%edx) <===
> > Code: c016570e <pfifo_fast_dequeue+1e/50> 3: 89 11 movl %edx,(%ecx)
> > Code: c0165710 <pfifo_fast_dequeue+20/50> 5: c7 00 00 00 00 movl $0x0,(%eax)
> > Code: c0165715 <pfifo_fast_dequeue+25/50> a: 00
> > Code: c0165716 <pfifo_fast_dequeue+26/50> b: c7 40 04 00 00 movl $0x0,0x4(%eax)
> > Code: c016571b <pfifo_fast_dequeue+2b/50> 10: 00 00
> > Code: c016571d <pfifo_fast_dequeue+2d/50> 12: c7 40 00 00 00 movl $0x0,0x0(%eax)
> > Code: c0165722 <pfifo_fast_dequeue+32/50> 17: 00 00
>
> This is in __skb_dequeue:
>
> prev = (struct sk_buff *) list;
> next = prev->next;
> result = NULL;
> if (next != prev) {
> result = next;
> next = next->next;
> list->qlen--;
> next->prev = prev; <-- here
> prev->next = next;
> result->next = NULL;
> result->prev = NULL;
> result->list = NULL;
> }
> return result;
>
> Somehow, list->next->next is NULL, even though it's a circular list.
Then it looks like the oops report isn't very helpful, as it's
pointing us to the results of the corrupted list rather than the place
where the list is being corrupted in the first place?
Is there any way we can pinpoint where things are going awry? Like I
said, this is on a uniprocessor machine, it's persisted through two
kernel revisions, it only occurs during one type of activity (IP
Masqing of certain connections) and it's easily repeatable. I'm not
above printk debugging (or is there a linux kernel equivalent of
assert()?) if there was some likely place to look.
--- Roy Stogner roystgnr@rice.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/