1. 27 9月, 2010 4 次提交
  2. 25 9月, 2010 2 次提交
    • O
      de2104x: disable autonegotiation on broken hardware · e0f9c4f3
      Ondrej Zary 提交于
      At least on older 21041-AA chips (mine is rev. 11), TP duplex autonegotiation
      causes the card not to work at all (link is up but no packets are transmitted).
      
      de4x5 disables autonegotiation completely. But it seems to work on newer
      (21041-PA rev. 21) so disable it only on rev<20 chips.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Acked-by: NJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0f9c4f3
    • E
      net: fix a lockdep splat · f064af1e
      Eric Dumazet 提交于
      We have for each socket :
      
      One spinlock (sk_slock.slock)
      One rwlock (sk_callback_lock)
      
      Possible scenarios are :
      
      (A) (this is used in net/sunrpc/xprtsock.c)
      read_lock(&sk->sk_callback_lock) (without blocking BH)
      <BH>
      spin_lock(&sk->sk_slock.slock);
      ...
      read_lock(&sk->sk_callback_lock);
      ...
      
      (B)
      write_lock_bh(&sk->sk_callback_lock)
      stuff
      write_unlock_bh(&sk->sk_callback_lock)
      
      (C)
      spin_lock_bh(&sk->sk_slock)
      ...
      write_lock_bh(&sk->sk_callback_lock)
      stuff
      write_unlock_bh(&sk->sk_callback_lock)
      spin_unlock_bh(&sk->sk_slock)
      
      This (C) case conflicts with (A) :
      
      CPU1 [A]                         CPU2 [C]
      read_lock(callback_lock)
      <BH>                             spin_lock_bh(slock)
      <wait to spin_lock(slock)>
                                       <wait to write_lock_bh(callback_lock)>
      
      We have one problematic (C) use case in inet_csk_listen_stop() :
      
      local_bh_disable();
      bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock)
      WARN_ON(sock_owned_by_user(child));
      ...
      sock_orphan(child); // write_lock_bh(&sk->sk_callback_lock)
      
      lockdep is not happy with this, as reported by Tetsuo Handa
      
      It seems only way to deal with this is to use read_lock_bh(callbacklock)
      everywhere.
      
      Thanks to Jarek for pointing a bug in my first attempt and suggesting
      this solution.
      Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Jarek Poplawski <jarkao2@gmail.com>
      Tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f064af1e
  3. 23 9月, 2010 16 次提交
  4. 22 9月, 2010 4 次提交
  5. 21 9月, 2010 6 次提交
  6. 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
  7. 17 9月, 2010 3 次提交