RTNL: assertion failed at net/core/dev.c

RTNL: assertion failed at net/core/dev.c

[Christian Kujau]

Wow, I should really update more often. Skipping the last -rc versions 
AND adding a new device (zd1211rw) to the box turns out to be quite 
interesting ([0],[1]).

However, this time loading of a (proprietary) module is involved. Knowing
that lkml cannot really help here (and I should contact vmware), I just 
wanted to let you netdev guys know, because the only occurences I found 
on the net were from 1999, but given the amount of changes currently 
going into net/ I thought this might be interesting:

[15604.137408] RTNL: assertion failed at net/core/dev.c (2595)
[15604.137772]  [<c0106aaa>] show_trace_log_lvl+0x1a/0x30
[15604.138121]  [<c0107682>] show_trace+0x12/0x20
[15604.138449]  [<c01076a5>] dump_stack+0x15/0x20
[15604.138807]  [<c038c612>] __dev_set_promiscuity+0xc2/0xd0
[15604.139163]  [<c038c9bb>] dev_set_promiscuity+0x1b/0x40
[15604.139515]  [<f91cb3fb>] VNetBridgeStartPromisc+0x2b/0x50 [vmnet]
[15604.139896]  [<f91cb61a>] VNetBridgePortsChanged+0x2a/0x40 [vmnet]
[15604.140276]  [<f91c9a65>] VNetHubPortsChanged+0x65/0xc0 [vmnet]
[15604.140648]  [<f91c869a>] VNetConnect+0x7a/0xb0 [vmnet]
[15604.141000]  [<f91c926d>] VNetFileOpOpen+0xbd/0x170 [vmnet]
[15604.141362]  [<c016b213>] chrdev_open+0x83/0x180
[15604.141696]  [<c0167321>] __dentry_open+0xa1/0x1a0
[15604.142036]  [<c01674c5>] nameidata_to_filp+0x35/0x40
[15604.142383]  [<c0167519>] do_filp_open+0x49/0x60
[15604.142717]  [<c0167575>] do_sys_open+0x45/0x80
[15604.142957]  [<c01675ec>] sys_open+0x1c/0x20
[15604.143087]  [<c010598a>] sysenter_past_esp+0x6b/0xb5
[15604.143227]  =======================

details: http://nerdbynature.de/bits/2.6.23-rc5/

Christian.

[0] http://www.spinics.net/lists/netdev/msg40247.html
[1] http://www.spinics.net/lists/netdev/msg40281.html
-- 
BOFH excuse #31:

cellular telephone interference

Re: RTNL: assertion failed at net/core/dev.c

[Stephen Hemminger]

On Sun, 2 Sep 2007 18:05:33 +0200 (CEST)
Christian Kujau <lists@nerdbynature.de> wrote:

> Wow, I should really update more often. Skipping the last -rc versions 
> AND adding a new device (zd1211rw) to the box turns out to be quite 
> interesting ([0],[1]).
> 
> However, this time loading of a (proprietary) module is involved. Knowing
> that lkml cannot really help here (and I should contact vmware), I just 
> wanted to let you netdev guys know, because the only occurences I found 
> on the net were from 1999, but given the amount of changes currently 
> going into net/ I thought this might be interesting:
> 
> [15604.137408] RTNL: assertion failed at net/core/dev.c (2595)
> [15604.137772]  [<c0106aaa>] show_trace_log_lvl+0x1a/0x30
> [15604.138121]  [<c0107682>] show_trace+0x12/0x20
> [15604.138449]  [<c01076a5>] dump_stack+0x15/0x20
> [15604.138807]  [<c038c612>] __dev_set_promiscuity+0xc2/0xd0
> [15604.139163]  [<c038c9bb>] dev_set_promiscuity+0x1b/0x40
> [15604.139515]  [<f91cb3fb>] VNetBridgeStartPromisc+0x2b/0x50 [vmnet]

Vendor module calls kernel api incorrectly. dev_set_promiscuity requires
that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug,
netdev doesn't want to hear about it.

Re: RTNL: assertion failed at net/core/dev.c

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Sun, 2007-09-02 at 18:05 +0200, Christian Kujau wrote:
> but given the amount of changes currently 
> going into net/ I thought this might be interesting:
> 
> [15604.137408] RTNL: assertion failed at net/core/dev.c (2595)

> [15604.138807]  [<c038c612>] __dev_set_promiscuity+0xc2/0xd0
> [15604.139163]  [<c038c9bb>] dev_set_promiscuity+0x1b/0x40
> [15604.139515]  [<f91cb3fb>] VNetBridgeStartPromisc+0x2b/0x50 [vmnet]

Not sure why this would be interesting. Clearly, dev_set_promiscuity is
called without the RTNL held while it should be. And see who the caller
is?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: RTNL: assertion failed at net/core/dev.c

[Christian Kujau]

On Sun, 2 Sep 2007, Stephen Hemminger wrote:
> Vendor module calls kernel api incorrectly. dev_set_promiscuity requires
> that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug,
> netdev doesn't want to hear about it.

OK, that's all I needed to know. Thank you both for your comments!

Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance