q == &noop_qdisc warning from 802.11 code

Hi,

I hit the warning from __netif_schedule:

wlan0: Trigger new scan to find an IBSS to join

------------[ cut here ]------------
WARNING: at net/core/dev.c:1334 __netif_schedule+0x6f/0x80()
Modules linked in: ath5k arc4 ecb crypto_blkcipher cryptomgr crypto_algapi mac80211 led_class usbhid cfg80211 ohci1394 hid ff_memless ieee1394 evdev rtc_cmos floppy [last unloaded: ath5k]

Pid: 4342, comm: ath5k_pci Not tainted 2.6.26-mm1_64 #429

Call Trace:
 [<ffffffff8023b3ff>] warn_on_slowpath+0x5f/0x90
 [<ffffffff802ac545>] ? check_object+0x235/0x270
 [<ffffffff802aae00>] ? init_object+0x50/0x90
 [<ffffffff802ad98d>] ? __slab_free+0x28d/0x360
 [<ffffffff8054bea3>] ? wireless_send_event+0x173/0x310
 [<ffffffffa009a843>] ? ath5k_hw_set_rx_filter+0x103/0x110 [ath5k]
 [<ffffffffa009a9e0>] ? ath5k_hw_set_mcast_filter+0x50/0x60 [ath5k]
 [<ffffffffa0098c23>] ? ath5k_configure_filter+0x1a3/0x200 [ath5k]
 [<ffffffff804bcb1f>] __netif_schedule+0x6f/0x80
 [<ffffffffa007b703>] ieee80211_scan_completed+0x243/0x300 [mac80211]
 [<ffffffffa007b84f>] ieee80211_sta_scan_work+0x8f/0x210 [mac80211]
 [<ffffffffa007b7c0>] ? ieee80211_sta_scan_work+0x0/0x210 [mac80211]
 [<ffffffff8024dc90>] run_workqueue+0x70/0x120
 [<ffffffff8024df47>] worker_thread+0xa7/0x120
 [<ffffffff802521b0>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8024dea0>] ? worker_thread+0x0/0x120
 [<ffffffff80251df9>] kthread+0x49/0x90
 [<ffffffff8020d549>] child_rip+0xa/0x11
 [<ffffffff80251db0>] ? kthread+0x0/0x90
 [<ffffffff8020d53f>] ? child_rip+0x0/0x11

---[ end trace bfbab62b1ce8da42 ]---

What causes it? I did:

# insmod  ath5k.ko
# iwconfig wlan0 mode ad-hoc
# iwconfig wlan0 channel 2 essid bubak

No link up, the link is still down:
6: wmaster0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000

    link/ieee802.11 00:0b:6b:80:f0:5d brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:0b:6b:80:f0:5d brd ff:ff:ff:ff:ff:ff

Is this a mac80211 issue?

I also hit a bug related to noop_qdisc running the net-next kernel.
I hit this bug every time I run "ifconfig eth0 mtu 9000; ifconfg eth0 1500" for any interface (tested against s2io and e1000) that is up, otherwise the bug isn't reproducible.

The bug dumps the following calltrace:

[root@io-dolphins net-next-2.6]# ifconfig eth0 mtu 9000; ifconfig eth0 mtu 1500

------------[ cut here ]------------
kernel BUG at net/core/dev.c:1328!
cpu 0x1: Vector: 700 (Program Check) at [c0000000be3d3460]
    pc: c0000000003603ac: .__netif_schedule+0x2c/0xb8
    lr: d00000000026b014: .s2io_change_mtu+0x1c4/0x27c [s2io]
    sp: c0000000be3d36e0

msr: 8000000000029032
current = 0xc0000000bc4042b0
paca = 0xc0000000006f3680
pid = 3496, comm = ifconfig
kernel BUG at net/core/dev.c:1328!
enter ? for help
[c0000000be3d3760] d00000000026b014 .s2io_change_mtu+0x1c4/0x27c [s2io] [c0000000be3d3800] c0000000003631ac .dev_set_mtu+0x68/0xb0 [c0000000be3d3880] c000000000364bc4 .dev_ioctl+0x67c/0x780 [c0000000be3d3990] c000000000354394 .sock_ioctl+0x2d8/0x310 [c0000000be3d3a30] c0000000001054b4 .vfs_ioctl+0x5c/0xf0 [c0000000be3d3ad0] c000000000105954 .do_vfs_ioctl+0x40c/0x448 [c0000000be3d3b80] c000000000105a00 .sys_ioctl+0x70/0xb4 [c0000000be3d3c30] c00000000013a2e8 .dev_ifsioc+0x1b0/0x3e4 [c0000000be3d3d40] c0000000001398a8 .compat_sys_ioctl+0x3d4/0x468 [c0000000be3d3e30] c0000000000086b4 syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 000000000ff15fe8
SP (ffecf8a0) is in userspace

And the code which is causing the bug is the following:

void __netif_schedule(struct Qdisc *q)

{
        BUG_ON(q == &noop_qdisc);

So, somehow we're reaching __netif_schedule() using a noop_qdisc.

Breno Leitao
[email protected]

Yeah, I'm looking into it. Just removing the netif_wake calls in mlme.c might work.

johannes

From: Johannes Berg <[email protected]>
Date: Wed, 23 Jul 2008 16:53:05 +0200

Don't work too hard on this now, I'm removing the warning as I mentioned in a recent posting.

Most important is the bug where wireless expects the SKB control block to be untouched across the qdisc layer, which was never true :-)