1. 29 Mar, 2011 3 commits
  2. 28 Mar, 2011 7 commits
  3. 24 Mar, 2011 7 commits
  4. 23 Mar, 2011 4 commits
    • Senthil Balasubramanian's avatar
      ath9k: Fix TX queue stuck issue. · d78f4b3e
      Senthil Balasubramanian authored
      commit 86271e46 introduced a
      regression that caused mac80211 queues in stopped state.
      
      ath_drain_all_txq is called in driver flush which would reset
      the stopped flag and the mac80211 queues were never started
      after that. iperf traffic is completely stalled due to this issue.
      
      Restart the mac80211 queues in driver flush only if the txqs were
      drained.
      Signed-off-by: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d78f4b3e
    • Senthil Balasubramanian's avatar
      ath9k: Fix kernel panic caused by invalid rate index access. · 19b96750
      Senthil Balasubramanian authored
      With the recent tx status optimization in mac80211, we bail out as
      and and when invalid rate index is found. So the behavior of resetting
      rate idx to -1 and count to 0 has changed for the rate indexes that
      were not part of the driver's retry series.
      
      This has resulted in ath9k using incorrect rate table index which
      caused the system to panic. Ideally ath9k need to loop only for the
      indexes that were part of the retry series and so simply use hw->max_rates
      as the loop counter.
      
      Pasted the stack trace of the panic issue for reference.
      
      [  754.093192] BUG: unable to handle kernel paging request at ffff88046a9025b0
      [  754.093256] IP: [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
      [  754.094888] Call Trace:
      [  754.094903]  <IRQ>
      [  754.094928]  [<ffffffffa051f883>] ieee80211_tx_status+0x203/0x9e0 [mac80211]
      [  754.094975]  [<ffffffffa053e305>] ? __ieee80211_wake_queue+0x125/0x140 [mac80211]
      [  754.095017]  [<ffffffffa02e66c9>] ath_tx_complete_buf+0x1b9/0x370 [ath9k]
      [  754.095054]  [<ffffffffa02e6fcf>] ath_tx_complete_aggr+0x51f/0xb50 [ath9k]
      [  754.095098]  [<ffffffffa05382a3>] ? ieee80211_prepare_and_rx_handle+0x173/0xab0 [mac80211]
      [  754.095148]  [<ffffffff81350e62>] ? _raw_spin_unlock_irqrestore+0x32/0x40
      [  754.095186]  [<ffffffffa02e9735>] ath_tx_tasklet+0x365/0x4b0 [ath9k]
      [  754.095224]  [<ffffffff8107a2a2>] ? clockevents_program_event+0x62/0xa0
      [  754.095261]  [<ffffffffa02e2628>] ath9k_tasklet+0x168/0x1c0 [ath9k]
      [  754.095298]  [<ffffffff8105599b>] tasklet_action+0x6b/0xe0
      [  754.095331]  [<ffffffff81056278>] __do_softirq+0x98/0x120
      [  754.095361]  [<ffffffff8100cd5c>] call_softirq+0x1c/0x30
      [  754.095393]  [<ffffffff8100efb5>] do_softirq+0x65/0xa0
      [  754.095423]  [<ffffffff810563fd>] irq_exit+0x8d/0x90
      [  754.095453]  [<ffffffff8100ebc1>] do_IRQ+0x61/0xe0
      [  754.095482]  [<ffffffff81351413>] ret_from_intr+0x0/0x15
      [  754.095513]  <EOI>
      [  754.095531]  [<ffffffff81014375>] ? native_sched_clock+0x15/0x70
      [  754.096475]  [<ffffffffa02bcfa6>] ? acpi_idle_enter_bm+0x24d/0x285 [processor]
      [  754.096475]  [<ffffffffa02bcf9f>] ? acpi_idle_enter_bm+0x246/0x285 [processor]
      [  754.096475]  [<ffffffff8127fab2>] cpuidle_idle_call+0x82/0x100
      [  754.096475]  [<ffffffff8100a236>] cpu_idle+0xa6/0xf0
      [  754.096475]  [<ffffffff81339bc1>] rest_init+0x91/0xa0
      [  754.096475]  [<ffffffff814efccd>] start_kernel+0x3fd/0x408
      [  754.096475]  [<ffffffff814ef347>] x86_64_start_reservations+0x132/0x136
      [  754.096475]  [<ffffffff814ef451>] x86_64_start_kernel+0x106/0x115
      [  754.096475] RIP  [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
      Signed-off-by: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19b96750
    • armadefuego@gmail.com's avatar
      orinoco: Clear dangling pointer on hardware busy · a3ad38e8
      armadefuego@gmail.com authored
      On hardware busy the scan request pointer should be cleared, as higher
      levels will release. This avoids a crash when that pointer is
      erroneously used later.
      Signed-off-by: default avatarJoseph J. Gunn <armadefuego@yahoo.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a3ad38e8
    • Johannes Berg's avatar
      iwlagn: fix error in command waiting · be36cacd
      Johannes Berg authored
      Clearly a mistake, since pointers won't suddenly
      change their value...
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      be36cacd
  5. 21 Mar, 2011 11 commits
  6. 20 Mar, 2011 7 commits
    • David S. Miller's avatar
    • David S. Miller's avatar
    • Vasiliy Kulikov's avatar
      netfilter: ipt_CLUSTERIP: fix buffer overflow · 961ed183
      Vasiliy Kulikov authored
      'buffer' string is copied from userspace.  It is not checked whether it is
      zero terminated.  This may lead to overflow inside of simple_strtoul().
      Changli Gao suggested to copy not more than user supplied 'size' bytes.
      
      It was introduced before the git epoch.  Files "ipt_CLUSTERIP/*" are
      root writable only by default, however, on some setups permissions might be
      relaxed to e.g. network admin user.
      Signed-off-by: default avatarVasiliy Kulikov <segoon@openwall.com>
      Acked-by: default avatarChangli Gao <xiaosuo@gmail.com>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      961ed183
    • Eric Dumazet's avatar
      netfilter: xtables: fix reentrancy · db856674
      Eric Dumazet authored
      commit f3c5c1bf (make ip_tables reentrant) introduced a race in
      handling the stackptr restore, at the end of ipt_do_table()
      
      We should do it before the call to xt_info_rdunlock_bh(), or we allow
      cpu preemption and another cpu overwrites stackptr of original one.
      
      A second fix is to change the underflow test to check the origptr value
      instead of 0 to detect underflow, or else we allow a jump from different
      hooks.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jan Engelhardt <jengelh@medozas.de>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      db856674
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: fix checking the type revision at create command · 5c1aba46
      Jozsef Kadlecsik authored
      The revision of the set type was not checked at the create command: if the
      userspace sent a valid set type but with not supported revision number,
      it'd create a loop.
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      5c1aba46
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: fix address ranges at hash:*port* types · 5e0c1eb7
      Jozsef Kadlecsik authored
      The hash:*port* types with IPv4 silently ignored when address ranges
      with non TCP/UDP were added/deleted from the set and used the first
      address from the range only.
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      5e0c1eb7
    • David S. Miller's avatar
      niu: Rename NIU parent platform device name to fix conflict. · a769f496
      David S. Miller authored
      When the OF device driver bits were converted over to the platform
      device infrastructure in commit 74888760
      ("dt/net: Eliminate users of of_platform_{,un}register_driver") we
      inadvertantly created probing problems in the OF case.
      
      The NIU driver creates a dummy platform device to represent the
      board that contains one or more child NIU devices.  Unfortunately
      we use the same name, "niu", as the OF device driver itself uses.
      
      The result is that we try to probe the dummy "niu" parent device we
      create, and since it has a NULL ofdevice pointer etc. everything
      explodes:
      
      [783019.128243] niu: niu.c:v1.1 (Apr 22, 2010)
      [783019.128810] Unable to handle kernel NULL pointer dereference
      [783019.128949] tsk->{mm,active_mm}->context = 000000000000039e
      [783019.129078] tsk->{mm,active_mm}->pgd = fffff803afc5a000
      [783019.129206]               \|/ ____ \|/
      [783019.129213]               "@'/ .. \`@"
      [783019.129220]               /_| \__/ |_\
      [783019.129226]                  \__U_/
      [783019.129378] modprobe(2004): Oops [#1]
      [783019.129423] TSTATE: 0000000011001602 TPC: 0000000010052ff8 TNPC: 000000000061bbb4 Y: 00000000    Not tainted
      [783019.129542] TPC: <niu_of_probe+0x3c/0x2dc [niu]>
      [783019.129624] g0: 8080000000000000 g1: 0000000000000000 g2: 0000000010056000 g3: 0000000000000002
      [783019.129733] g4: fffff803fc1da0c0 g5: fffff800441e2000 g6: fffff803fba84000 g7: 0000000000000000
      [783019.129842] o0: fffff803fe7df010 o1: 0000000010055700 o2: 0000000000000000 o3: fffff803fbacaca0
      [783019.129951] o4: 0000000000000080 o5: 0000000000777908 sp: fffff803fba866e1 ret_pc: 0000000010052ff4
      [783019.130083] RPC: <niu_of_probe+0x38/0x2dc [niu]>
      [783019.130165] l0: fffff803fe7df010 l1: fffff803fbacafc0 l2: fffff803fbacaca0 l3: ffffffffffffffed
      [783019.130273] l4: 0000000000000000 l5: 000000007fffffff l6: fffff803fba86f40 l7: 0000000000000001
      [783019.130382] i0: fffff803fe7df000 i1: fffff803fc20aba0 i2: 0000000000000000 i3: 0000000000000001
      [783019.130490] i4: 0000000000000000 i5: 0000000000000000 i6: fffff803fba867a1 i7: 000000000062038c
      [783019.130614] I7: <platform_drv_probe+0xc/0x20>
      
      Fix by simply renaming the parent device to "niu-board".
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a769f496
  7. 19 Mar, 2011 1 commit