1. 22 4月, 2012 2 次提交
    • W
      net/hyperv: Adding cancellation to ensure rndis filter is closed · 792df872
      Wenqi Ma 提交于
      Although the network interface is down, the RX packets number which
      could be observed by ifconfig may keep on increasing.
      
      This is because the WORK scheduled in netvsc_set_multicast_list()
      may be executed after netvsc_close(). That means the rndis filter
      may be re-enabled by do_set_multicast() even if it was closed by
      netvsc_close().
      
      By canceling possible WORK before close the rndis filter, the issue
      could be never happened.
      Signed-off-by: NWenqi Ma <wenqi_ma@trendmicro.com.cn>
      Reviewed-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      792df872
    • S
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      Stephen Boyd 提交于
      There is a potential deadlock scenario when the ks8851 driver
      is removed. The interrupt handler schedules a workqueue which
      acquires a mutex that ks8851_net_stop() also acquires before
      flushing the workqueue. Previously lockdep wouldn't be able
      to find this problem but now that it has the support we can
      trigger this lockdep warning by rmmoding the driver after
      an ifconfig up.
      
      Fix the possible deadlock by disabling the interrupts in
      the chip and then release the lock across the workqueue
      flushing. The mutex is only there to proect the registers
      anyway so this should be ok.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      3.0.21-00021-g8b33780-dirty #2911
      -------------------------------------------------------
      rmmod/125 is trying to acquire lock:
       ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
      
      but task is already holding lock:
       (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&ks->lock){+.+...}:
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c083dbec>] mutex_lock_nested+0x68/0x3dc
             [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
             [<c019c580>] process_one_work+0x2d8/0x518
             [<c019cb98>] worker_thread+0x220/0x3a0
             [<c01a2ad4>] kthread+0x88/0x94
             [<c0107008>] kernel_thread_exit+0x0/0x8
      
      -> #0 ((&ks->irq_work)){+.+...}:
             [<c01b7984>] validate_chain+0x914/0x1018
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c019e104>] flush_work+0x4c/0xac
             [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
             [<c06b209c>] __dev_close_many+0x98/0xcc
             [<c06b2174>] dev_close_many+0x68/0xd0
             [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
             [<c06b2554>] rollback_registered+0x28/0x34
             [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
             [<c06b25f4>] unregister_netdev+0x18/0x20
             [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
             [<c049ddf0>] spi_drv_remove+0x18/0x1c
             [<c0468e98>] __device_release_driver+0x7c/0xbc
             [<c0468f64>] driver_detach+0x8c/0xb4
             [<c0467f00>] bus_remove_driver+0xb8/0xe8
             [<c01c1d20>] sys_delete_module+0x1e8/0x27c
             [<c0105ec0>] ret_fast_syscall+0x0/0x3c
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&ks->lock);
                                     lock((&ks->irq_work));
                                     lock(&ks->lock);
        lock((&ks->irq_work));
      
       *** DEADLOCK ***
      
      4 locks held by rmmod/125:
       #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
       #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
       #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
       #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5a99937
  2. 20 4月, 2012 5 次提交
  3. 19 4月, 2012 3 次提交
    • E
      tcp: fix retransmit of partially acked frames · 22b4a4f2
      Eric Dumazet 提交于
      Alexander Beregalov reported skb_over_panic errors and provided stack
      trace.
      
      I occurs commit a21d4572 (tcp: avoid order-1 allocations on wifi and
      tx path) added a regression, when a retransmit is done after a partial
      ACK.
      
      tcp_retransmit_skb() tries to aggregate several frames if the first one
      has enough available room to hold the following ones payload. This is
      controlled by /proc/sys/net/ipv4/tcp_retrans_collapse tunable (default :
      enabled)
      
      Problem is we must make sure _pskb_trim_head() doesnt fool
      skb_availroom() when pulling some bytes from skb (this pull is done when
      receiver ACK part of the frame).
      Reported-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Cc: Marc MERLIN <marc@merlins.org>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22b4a4f2
    • D
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 56fa9b16
      David S. Miller 提交于
      From John:
      
      Another batch of fixes intended for 3.4...
      
      First up, we have a minor signedness fix for libertas from Amitkumar
      Karwar.  Next, Arend gives us a brcm80211 fix for correctly enabling
      Tx FIFOs on channels 12 and 13.  Bing Zhao gives us some register
      address corrections for mwifiex.  Felix give us a trio of fixes --
      one for ath9k to wake the hardware properly from full sleep, one for
      mac80211 to properly handle packets in cooked monitor mode, and one
      for ensuring that the proper HT mode selection is honored.
      
      Hauke gives us a bcma fix for handling the lack of an sprom.  Jonathon
      Bither gives us an ath5k fix for a missing THIS_MODULE build issue,
      and another ath5k fix for an io mapping leak.  Lukasz Kucharczyk
      fixes a bitwise check in cfg80211, and Sujith gives us an ath9k fix
      for assigning sequence numbers for fragmented frames.  Finally, we
      have a MAINTAINERS change from Wey-Yi Guy -- congrats to Johannes
      Berg for taking the lead on iwlwifi. :-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56fa9b16
    • J
      Merge branch 'master' of... · dbd717e3
      John W. Linville 提交于
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      dbd717e3
  4. 18 4月, 2012 15 次提交
  5. 17 4月, 2012 6 次提交
  6. 15 4月, 2012 1 次提交
    • D
      net/ethernet: ks8851_mll fix rx frame buffer overflow · 8a9a0ea6
      Davide Ciminaghi 提交于
      At the beginning of ks_rcv(), a for loop retrieves the
      header information relevant to all the frames stored
      in the mac's internal buffers. The number of pending
      frames is stored as an 8 bits field in KS_RXFCTR.
      If interrupts are disabled long enough to allow for more than
      32 frames to accumulate in the MAC's internal buffers, a buffer
      overflow occurs.
      This patch fixes the problem by making the
      driver's frame_head_info buffer big enough.
      Well actually, since the chip appears to have 12K of
      internal rx buffers and the shortest ethernet frame should
      be 64 bytes long, maybe the limit could be set to
      12*1024/64 = 192 frames, but 255 should be safer.
      Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com>
      Signed-off-by: NRaffaele Recalcati <raffaele.recalcati@bticino.it>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a9a0ea6
  7. 14 4月, 2012 8 次提交