1. 15 7月, 2008 1 次提交
    • I
      rt2x00: Fix NULL pointer error in adhoc/master mode · 9a613195
      Ivo van Doorn 提交于
      As soon as an interface is enabled, and that interface is in adhoc or master mode,
      the device will start raising beacondone interrupts. But before the first interrupt is
      raised, mac80211 will probably not have send any beacons to the device yet, which
      results in a NULL pointer error when the skb is being freed.
      
      Note that the "raise beacondone interrupts without a beacon" is also a bug,
      and will be addressed later. The more important bug however is preventing
      the NULL pointer failt itself, since there might be other conditions that could trigger
      it as well.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a613195
  2. 09 7月, 2008 1 次提交
  3. 27 6月, 2008 5 次提交
  4. 15 6月, 2008 5 次提交
  5. 22 5月, 2008 4 次提交
  6. 08 5月, 2008 1 次提交
  7. 14 3月, 2008 1 次提交
    • I
      rt2x00: Upgrade queue->lock to use irqsave · 5f46c4d0
      Ivo van Doorn 提交于
      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: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5f46c4d0
  8. 01 3月, 2008 5 次提交