1. 14 Jun, 2008 5 commits
  2. 21 May, 2008 4 commits
  3. 07 May, 2008 1 commit
  4. 13 Mar, 2008 1 commit
    • 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
  5. 29 Feb, 2008 5 commits