[Top] [All Lists]

Re: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/n

To: Ingo Molnar <mingo@xxxxxxx>
Subject: Re: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (126)
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 30 Mar 2005 18:26:40 +1000
Cc: netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, olel@xxxxxx
In-reply-to: <20050329114926.GA14986@xxxxxxx>
References: <20050327091524.GA23215@xxxxxxx> <E1DFUaZ-0001Hg-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050327133811.GA5569@xxxxxxx> <20050329104906.GA19836@xxxxxxxxxxxxxxxxxxx> <20050329114926.GA14986@xxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Tue, Mar 29, 2005 at 01:49:26PM +0200, Ingo Molnar wrote:
> (i guess the debug message should be extended to do a dump_stack() so 
> that we see which process does?)

Never mind.  I think I've found what it is.  The only thing I can't
figure out is why we're only seeing it now when this bug has been
around since day one.

In netlink_dump we're operating on sk after dropping the cb lock.
This is racy because the owner of the socket could close it after
we drop the cb lock.

This is possible because netlink_dump isn't always called from the
context of the process that owns the socket.  For instance, if there
is contention on rtnl then rtnetlink requests will be processed by
the process that owns the rtnl.

The solution is to hold a ref count on the socket before we drop
the cb lock.

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>