1. 23 9月, 2010 11 次提交
  2. 22 9月, 2010 4 次提交
  3. 21 9月, 2010 6 次提交
  4. 18 9月, 2010 5 次提交
    • E
      qlcnic: dont assume NET_IP_ALIGN is 2 · 04746ff1
      Eric Dumazet 提交于
      qlcnic driver allocates rx skbs and gives to hardware too bytes of extra
      storage, allowing for corruption of kernel data.
      
      NET_IP_ALIGN being 0 on some platforms (including x86), drivers should
      not assume it's 2.
      
      rds_ring->skb_size = rds_ring->dma_size + NET_IP_ALIGN;
      ...
      skb = dev_alloc_skb(rds_ring->skb_size);
      skb_reserve(skb, 2);
      pci_map_single(pdev, skb->data, rds_ring->dma_size, PCI_DMA_FROMDEVICE);
      
      (and rds_ring->skb_size == rds_ring->dma_size) -> bug
      
      
      Because of extra alignment (1500 + 32) -> four extra bytes are available
      before the struct skb_shared_info, so corruption is not noticed.
      
      Note: this driver could use netdev_alloc_skb_ip_align()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      04746ff1
    • S
      dca: disable dca on IOAT ver.3.0 multiple-IOH platforms · 4e8cec26
      Sosnowski, Maciej 提交于
      Direct Cache Access is not supported on IOAT ver.3.0 multiple-IOH platforms.
      This patch blocks registering of dca providers when multiple IOH detected with IOAT ver.3.0.
      Signed-off-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e8cec26
    • H
      netpoll: Disable IRQ around RCU dereference in netpoll_rx · f0f9deae
      Herbert Xu 提交于
      We cannot use rcu_dereference_bh safely in netpoll_rx as we may
      be called with IRQs disabled.  We could however simply disable
      IRQs as that too causes BH to be disabled and is safe in either
      case.
      
      Thanks to John Linville for discovering this bug and providing
      a patch.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0f9deae
    • V
      sctp: Do not reset the packet during sctp_packet_config(). · 4bdab433
      Vlad Yasevich 提交于
      sctp_packet_config() is called when getting the packet ready
      for appending of chunks.  The function should not touch the
      current state, since it's possible to ping-pong between two
      transports when sending, and that can result packet corruption
      followed by skb overlfow crash.
      Reported-by: NThomas Dreibholz <dreibh@iem.uni-due.de>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bdab433
    • W
      iwlwifi: do not perferm force reset while doing scan · 7acc7c68
      Wey-Yi Guy 提交于
      When uCode error condition detected, driver try to perform either
      rf reset or firmware reload in order bring device back to
      working condition.
      
      If rf reset is required and scan is in process, there is no need
      to issue rf reset since scan already reset the rf.
      
      If firmware reload is required and scan is in process, skip the
      reload request. There is a possibility firmware reload during
      scan cause problem.
      
      [  485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
      [  485.804049] Hardware name: Latitude E6400
      [  485.804052] ieee80211_restart_hw called with hardware scan in progress
      [  485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
      [  485.804069] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804072] Call Trace:
      [  485.804079]  [<c103019a>] warn_slowpath_common+0x60/0x75
      [  485.804084]  [<c1030213>] warn_slowpath_fmt+0x26/0x2a
      [  485.804089]  [<c145da67>] ieee80211_restart_hw+0x28/0x62
      [  485.804102]  [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
      [  485.804108]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804119]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804124]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804128]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804133]  [<c10451b0>] kthread+0x64/0x69
      [  485.804137]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804141]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      [  485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
      [  485.804148] WG> 1
      [  485.804153] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804156] Call Trace:
      [  485.804161]  [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
      [  485.804172]  [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
      [  485.804177]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804188]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804192]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804197]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804201]  [<c10451b0>] kthread+0x64/0x69
      [  485.804205]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804209]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      7acc7c68
  5. 17 9月, 2010 6 次提交
  6. 16 9月, 2010 3 次提交
    • M
      r8169: Handle rxfifo errors on 8168 chips · 801e147c
      Matthew Garrett 提交于
      The Thinkpad X100e seems to have some odd behaviour when the display is
      powered off - the onboard r8169 starts generating rxfifo overflow errors.
      The root cause of this has not yet been identified and may well be a
      hardware design bug on the platform, but r8169 should be more resiliant to
      this. This patch enables the rxfifo interrupt on 8168 devices and removes
      the MAC version check in the interrupt handler, and the machine no longer
      crashes when under network load while the screen turns off.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      801e147c
    • D
      3c59x: Remove atomic context inside vortex_{set|get}_wol · 84176b7b
      Denis Kirjanov 提交于
      There is no need to use spinlocks in vortex_{set|get}_wol.
      This also fixes a bug:
      [  254.214993] 3c59x 0000:00:0d.0: PME# enabled
      [  254.215021] BUG: sleeping function called from invalid context at kernel/mutex.c:94
      [  254.215030] in_atomic(): 0, irqs_disabled(): 1, pid: 4875, name: ethtool
      [  254.215042] Pid: 4875, comm: ethtool Tainted: G        W   2.6.36-rc3+ #7
      [  254.215049] Call Trace:
      [  254.215050]  [] __might_sleep+0xb1/0xb6
      [  254.215050]  [] mutex_lock+0x17/0x30
      [  254.215050]  [] acpi_enable_wakeup_device_power+0x2b/0xb1
      [  254.215050]  [] acpi_pm_device_sleep_wake+0x42/0x7f
      [  254.215050]  [] acpi_pci_sleep_wake+0x5d/0x63
      [  254.215050]  [] platform_pci_sleep_wake+0x1d/0x20
      [  254.215050]  [] __pci_enable_wake+0x90/0xd0
      [  254.215050]  [] acpi_set_WOL+0x8e/0xf5 [3c59x]
      [  254.215050]  [] vortex_set_wol+0x4e/0x5e [3c59x]
      [  254.215050]  [] dev_ethtool+0x1cf/0xb61
      [  254.215050]  [] ? debug_mutex_free_waiter+0x45/0x4a
      [  254.215050]  [] ? __mutex_lock_common+0x204/0x20e
      [  254.215050]  [] ? __mutex_lock_slowpath+0x12/0x15
      [  254.215050]  [] ? mutex_lock+0x23/0x30
      [  254.215050]  [] dev_ioctl+0x42c/0x533
      [  254.215050]  [] ? _cond_resched+0x8/0x1c
      [  254.215050]  [] ? lock_page+0x1c/0x30
      [  254.215050]  [] ? page_address+0x15/0x7c
      [  254.215050]  [] ? filemap_fault+0x187/0x2c4
      [  254.215050]  [] sock_ioctl+0x1d4/0x1e0
      [  254.215050]  [] ? sock_ioctl+0x0/0x1e0
      [  254.215050]  [] vfs_ioctl+0x19/0x33
      [  254.215050]  [] do_vfs_ioctl+0x424/0x46f
      [  254.215050]  [] ? selinux_file_ioctl+0x3c/0x40
      [  254.215050]  [] sys_ioctl+0x40/0x5a
      [  254.215050]  [] sysenter_do_call+0x12/0x22
      
      vortex_set_wol protected with a spinlock, but nested  acpi_set_WOL acquires a mutex inside atomic context.
      Ethtool operations are already serialized by RTNL mutex, so it is safe to drop the locks.
      Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84176b7b
    • A
      tcp: Prevent overzealous packetization by SWS logic. · 01f83d69
      Alexey Kuznetsov 提交于
      If peer uses tiny MSS (say, 75 bytes) and similarly tiny advertised
      window, the SWS logic will packetize to half the MSS unnecessarily.
      
      This causes problems with some embedded devices.
      
      However for large MSS devices we do want to half-MSS packetize
      otherwise we never get enough packets into the pipe for things
      like fast retransmit and recovery to work.
      
      Be careful also to handle the case where MSS > window, otherwise
      we'll never send until the probe timer.
      Reported-by: Nツ Leandro Melo de Sales <leandroal@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01f83d69
  7. 15 9月, 2010 4 次提交
  8. 14 9月, 2010 1 次提交
    • M
      vhost-net: fix range checking in mrg bufs case · ee05d693
      Michael S. Tsirkin 提交于
      In mergeable buffer case, we use headcount, log_num
      and seg as indexes in same-size arrays, and
      we know that headcount <= seg and
      log_num equals either 0 or seg.
      
      Therefore, the right thing to do is range-check seg,
      not headcount as we do now: these will be different
      if guest chains s/g descriptors (this does not
      happen now, but we can not trust the guest).
      
      Long term, we should add BUG_ON checks to verify
      two other indexes are what we think they should be.
      Reported-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      ee05d693