Oops in inlined __skb_dequeue in unix_stream_recvmsg

Oops in inlined __skb_dequeue in unix_stream_recvmsg

[Jeremy Brown]

Roughly once a day, and usually when I'm not looking, my desktop will
wedge hard with 2.5.68. Most of the time I get no output to my serial
console, even with nmi_watchdog enabled. However, I have now gotten
three oopses, two of them clean, and they all point to the inlined
skb_dequeue() in unix_stream_recvmsg() in net/unix/af_unix.c.

static inline struct sk_buff *__skb_dequeue(struct sk_buff_head *list)
{
	struct sk_buff *next, *prev, *result;

	prev = (struct sk_buff *) list;
	next = prev->next;
	result = NULL;
	if (next != prev) {
		result	     = next;
		next	     = next->next;
		list->qlen--;
		next->prev   = prev;         <<<<<<< OOPS here
		prev->next   = next;
		result->next = result->prev = NULL;
		result->list = NULL;
	}
	return result;
}

In this case, "next" is NULL (after it has been assigned to
next->next, which is just list->next->next, or the second member of
the circularly linked list).

I've put the ksymoops output, system information, and .config on the
following page (44 KB):

http://www.geocities.com/antinousj/oops3.html

(I'm sorry if the Geocities stuff hurls popups at you or something;
it's just a convenient place to publish at the moment.)

I've been noticing this behavior since 2.5.65, but I've only been able
to capture it in 2.5.67 and 2.5.68 due to the fact that I ran out of
magic smoke in my serial terminal and needed some time to air out the
office and find a replacement.

I would be delighted if anybody had a suggestion.

Jeremy Brown