|To:||Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>|
|Subject:||Re: KERNEL: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (126)|
|From:||Krzysztof Oledzki <olel@xxxxxx>|
|Date:||Thu, 31 Mar 2005 22:00:05 +0200 (CEST)|
|Cc:||Ingo Molnar <mingo@xxxxxxx>, netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>|
|References:||<20050327091524.GA23215@xxxxxxx> <E1DFUaZ-0001Hg-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050327133811.GA5569@xxxxxxx> <20050329104906.GA19836@xxxxxxxxxxxxxxxxxxx> <20050329114926.GA14986@xxxxxxx> <20050330082640.GA8269@xxxxxxxxxxxxxxxxxxx>|
On Wed, 30 Mar 2005, Herbert Xu wrote:
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.
OK. I'm no longer able to trigger this error. And the patch is already in the linux-2.6 repository. Thank you.
Best regards, Krzysztof Olędzki
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics, Rik van Riel|
|Next by Date:||Re: [RFC/PATCH] network configs: disconnect network options from drivers, Randy.Dunlap|
|Previous by Thread:|
|Next by Thread:||[2.6 patch] drivers/net/wan/: possible cleanups, Adrian Bunk|
|Indexes:||[Date] [Thread] [Top] [All Lists]|