• Ivo van Doorn's avatar
    rt2x00: Upgrade queue->lock to use irqsave · 5f46c4d0
    Ivo van Doorn authored
    
    
    The queue->lock could be grabbed from interrupt context,
    which could lead to lockdep panic like this:
    
    kernel: ======================================================
    kernel: [ INFO: soft-safe -> soft-unsafe lock order detected ]
    kernel: 2.6.25-0.95.rc4.fc9 #1
    kernel: ------------------------------------------------------
    kernel: rt2500pci/1251 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire:
    kernel:  (&queue->lock){--..}, at: [<ffffffff88213339>] rt2x00queue_get_entry+0x5a/0x81 [rt2x00lib]
    kernel:
    kernel: and this task is already holding:
    kernel:  (_xmit_IEEE80211){-...}, at: [<ffffffff8122e9a3>] __qdisc_run+0x84/0x1a9
    kernel: which would create a new lock dependency:
    kernel:  (_xmit_IEEE80211){-...} -> (&queue->lock){--..}
    kernel:
    kernel: but this new dependency connects a soft-irq-safe lock:
    kernel:  (_xmit_ETHER){-+..}
    kernel: ... which became soft-irq-safe at:
    kernel:   [<ffffffffffffffff>] 0xffffffffffffffff
    kernel:
    kernel: to a soft-irq-unsafe lock:
    kernel:  (&queue->lock){--..}
    kernel: ... which became soft-irq-unsafe at:
    kernel: ...  [<ffffffff810545a2>] __lock_acquire+0x62d/0xd63
    kernel:   [<ffffffff81054d36>] lock_acquire+0x5e/0x78
    kernel:   [<ffffffff812a1497>] _spin_lock+0x26/0x53
    kernel:   [<ffffffff88212f98>] rt2x00queue_reset+0x16/0x40 [rt2x00lib]
    kernel:   [<ffffffff88212fd4>] rt2x00queue_alloc_entries+0x12/0xab [rt2x00lib]
    kernel:   [<ffffffff88213091>] rt2x00queue_initialize+0x24/0xf2 [rt2x00lib]
    kernel:   [<ffffffff88212036>] rt2x00lib_start+0x3b/0xd4 [rt2x00lib]
    kernel:   [<ffffffff88212609>] rt2x00mac_start+0x18/0x1a [rt2x00lib]
    kernel:   [<ffffffff881b9a4b>] ieee80211_open+0x1f3/0x46d [mac80211]
    kernel:   [<ffffffff8121d980>] dev_open+0x4d/0x8b
    kernel:   [<ffffffff8121d41e>] dev_change_flags+0xaf/0x172
    kernel:   [<ffffffff81224fc2>] do_setlink+0x276/0x338
    kernel:   [<ffffffff81225198>] rtnl_setlink+0x114/0x116
    kernel:   [<ffffffff812262fc>] rtnetlink_rcv_msg+0x1d8/0x1f9
    kernel:   [<ffffffff8123649a>] netlink_rcv_skb+0x3e/0xac
    kernel:   [<ffffffff8122611a>] rtnetlink_rcv+0x29/0x33
    kernel:   [<ffffffff81235eed>] netlink_unicast+0x1fe/0x26b
    kernel:   [<ffffffff81236224>] netlink_sendmsg+0x2ca/0x2dd
    kernel:   [<ffffffff812103b3>] sock_sendmsg+0xfd/0x120
    kernel:   [<ffffffff812105a8>] sys_sendmsg+0x1d2/0x23c
    kernel:   [<ffffffff8100c1c7>] tracesys+0xdc/0xe1
    kernel:   [<ffffffffffffffff>] 0xffffffffffffffff
    
    This can be fixed by using the irqsave/irqrestore versions
    during the queue->lock handling.
    Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    5f46c4d0
rt2x00queue.c 6.87 KB