On Mon, 9 Feb 2004 14:01:34 +0100
Petr Vandrovec <vandrove@xxxxxxxxxx> wrote:
> It looks to me like that we've got skb on completion_queue which was connected
> to a bit unhappy socket - one which had sk->sk_sleep uninitialized. Only
> is that only af_unix sets skb->destructor to sock_wfree, so I somehow miss
> this could be triggered by e100 link change.
It is not only af_unix, any time we invoke skb_set_owner_w() we get sock_wfree()
as the destructor, furthermore sock_def_write_space is the default such handler
given to all sockets unless they override that.
Maybe e100 is mangling it's TX queue or in fact freeing things twice.
I think what might be happening is that somehow the TX queue is corrupted if
e100_config() runs (due to link UP state change) while there are active normal
SKB packets on the TX queue. Or perhaps some TX queue handling locking issue.
Scott, any ideas?