1. 26 Sep, 2010 3 commits
  2. 24 Sep, 2010 2 commits
    • Ondrej Zary's avatar
      de2104x: disable autonegotiation on broken hardware · e0f9c4f3
      Ondrej Zary authored
      
      
      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: default avatarOndrej Zary <linux@rainbow-software.org>
      Acked-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0f9c4f3
    • Eric Dumazet's avatar
      net: fix a lockdep splat · f064af1e
      Eric Dumazet authored
      
      
      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: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Tested-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      CC: Jarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f064af1e
  3. 22 Sep, 2010 16 commits
  4. 21 Sep, 2010 4 commits
  5. 20 Sep, 2010 6 commits
  6. 17 Sep, 2010 5 commits
    • Eric Dumazet's avatar
      qlcnic: dont assume NET_IP_ALIGN is 2 · 04746ff1
      Eric Dumazet authored
      
      
      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: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04746ff1
    • Sosnowski, Maciej's avatar
      dca: disable dca on IOAT ver.3.0 multiple-IOH platforms · 4e8cec26
      Sosnowski, Maciej authored
      
      
      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: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e8cec26
    • Herbert Xu's avatar
      netpoll: Disable IRQ around RCU dereference in netpoll_rx · f0f9deae
      Herbert Xu authored
      
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0f9deae
    • Vlad Yasevich's avatar
      sctp: Do not reset the packet during sctp_packet_config(). · 4bdab433
      Vlad Yasevich authored
      
      
      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: default avatarThomas Dreibholz <dreibh@iem.uni-due.de>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bdab433
    • Wey-Yi Guy's avatar
      iwlwifi: do not perferm force reset while doing scan · 7acc7c68
      Wey-Yi Guy authored
      
      
      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: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      7acc7c68
  7. 16 Sep, 2010 4 commits