1. 27 Jun, 2012 4 commits
  2. 26 Jun, 2012 2 commits
    • Alexander Duyck's avatar
      ixgbe: Do not pad FCoE frames as this can cause issues with FCoE DDP · 57efd44c
      Alexander Duyck authored
      FCoE target mode was experiencing issues due to the fact that we were
      sending up data frames that were padded to 60 bytes after the DDP logic had
      already stripped the frame down to 52 or 56 depending on the use of VLANs.
      This was resulting in the FCoE DDP logic having issues since it thought the
      frame still had data in it due to the padding.
      
      To resolve this, adding code so that we do not pad FCoE frames prior to
      handling them to the stack.
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57efd44c
    • Eric Dumazet's avatar
      net: l2tp_eth: use LLTX to avoid LOCKDEP splats · a2842a1e
      Eric Dumazet authored
      Denys Fedoryshchenko reported a LOCKDEP issue with l2tp code.
      
      [ 8683.927442] ======================================================
      [ 8683.927555] [ INFO: possible circular locking dependency detected ]
      [ 8683.927672] 3.4.1-build-0061 #14 Not tainted
      [ 8683.927782] -------------------------------------------------------
      [ 8683.927895] swapper/0/0 is trying to acquire lock:
      [ 8683.928007]  (slock-AF_INET){+.-...}, at: [<e0fc73ec>]
      l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]
      [ 8683.928121] but task is already holding lock:
      [ 8683.928121]  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      sch_direct_xmit+0x36/0x119
      [ 8683.928121]
      [ 8683.928121] which lock already depends on the new lock.
      [ 8683.928121]
      [ 8683.928121]
      [ 8683.928121] the existing dependency chain (in reverse order) is:
      [ 8683.928121]
      [ 8683.928121] -> #1 (_xmit_ETHER#2){+.-...}:
      [ 8683.928121]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<c0304e0c>] ip_send_reply+0xf2/0x1ce
      [ 8683.928121]        [<c0317dbc>] tcp_v4_send_reset+0x153/0x16f
      [ 8683.928121]        [<c0317f4a>] tcp_v4_do_rcv+0x172/0x194
      [ 8683.928121]        [<c031929b>] tcp_v4_rcv+0x387/0x5a0
      [ 8683.928121]        [<c03001d0>] ip_local_deliver_finish+0x13a/0x1e9
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c030075b>] ip_local_deliver+0x41/0x45
      [ 8683.928121]        [<c03005dd>] ip_rcv_finish+0x31a/0x33c
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c0300960>] ip_rcv+0x201/0x23d
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02deae8>] netif_receive_skb+0x4e/0x7d
      [ 8683.928121]        [<e08d5ef3>] rtl8139_poll+0x243/0x33d [8139too]
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]
      [ 8683.928121] -> #0 (slock-AF_INET){+.-...}:
      [ 8683.928121]        [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e
      [l2tp_core]
      [ 8683.928121]        [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f
      [l2tp_eth]
      [ 8683.928121]        [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]        [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]        [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]        [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]        [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]
      [ 8683.928121] other info that might help us debug this:
      [ 8683.928121]
      [ 8683.928121]  Possible unsafe locking scenario:
      [ 8683.928121]
      [ 8683.928121]        CPU0                    CPU1
      [ 8683.928121]        ----                    ----
      [ 8683.928121]   lock(_xmit_ETHER#2);
      [ 8683.928121]                                lock(slock-AF_INET);
      [ 8683.928121]                                lock(_xmit_ETHER#2);
      [ 8683.928121]   lock(slock-AF_INET);
      [ 8683.928121]
      [ 8683.928121]  *** DEADLOCK ***
      [ 8683.928121]
      [ 8683.928121] 3 locks held by swapper/0/0:
      [ 8683.928121]  #0:  (rcu_read_lock){.+.+..}, at: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #1:  (rcu_read_lock_bh){.+....}, at: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #2:  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      sch_direct_xmit+0x36/0x119
      [ 8683.928121]
      [ 8683.928121] stack backtrace:
      [ 8683.928121] Pid: 0, comm: swapper/0 Not tainted 3.4.1-build-0061 #14
      [ 8683.928121] Call Trace:
      [ 8683.928121]  [<c034bdd2>] ? printk+0x18/0x1a
      [ 8683.928121]  [<c0158904>] print_circular_bug+0x1ac/0x1b6
      [ 8683.928121]  [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]  [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth]
      [ 8683.928121]  [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]  [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]  [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]  [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]  [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]  [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]  [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]  [<c012b23a>] ? local_bh_enable+0xd/0xd
      [ 8683.928121]  <IRQ>  [<c012b4d0>] ? irq_exit+0x41/0x91
      [ 8683.928121]  [<c0103c6f>] ? do_IRQ+0x79/0x8d
      [ 8683.928121]  [<c0157ea1>] ? trace_hardirqs_off_caller+0x2e/0x86
      [ 8683.928121]  [<c034ef6e>] ? common_interrupt+0x2e/0x34
      [ 8683.928121]  [<c0108a33>] ? default_idle+0x23/0x38
      [ 8683.928121]  [<c01091a8>] ? cpu_idle+0x55/0x6f
      [ 8683.928121]  [<c033df25>] ? rest_init+0xa1/0xa7
      [ 8683.928121]  [<c033de84>] ? __read_lock_failed+0x14/0x14
      [ 8683.928121]  [<c0498745>] ? start_kernel+0x303/0x30a
      [ 8683.928121]  [<c0498209>] ? repair_env_string+0x51/0x51
      [ 8683.928121]  [<c04980a8>] ? i386_start_kernel+0xa8/0xaf
      
      It appears that like most virtual devices, l2tp should be converted to
      LLTX mode.
      
      This patch takes care of statistics using atomic_long in both RX and TX
      paths, and fix a bug in l2tp_eth_dev_recv(), which was caching skb->data
      before a pskb_may_pull() call.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDenys Fedoryshchenko <denys@visp.net.lb>
      Cc: James Chapman <jchapman@katalix.com>
      Cc: Hong zhi guo <honkiko@gmail.com>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2842a1e
  3. 25 Jun, 2012 11 commits
  4. 23 Jun, 2012 8 commits
    • Antonio Quartulli's avatar
      batman-adv: fix race condition in TT full-table replacement · 8b8e4bc0
      Antonio Quartulli authored
      bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a
      
      In the current TT code, when a TT_Response containing a full table is received
      from an originator, first the node purges all the clients for that originator in
      the global translation-table and then merges the newly received table.
      During the purging phase each client deletion is done by means of a call_rcu()
      invocation and at the end of this phase the global entry counter for that
      originator is set to 0. However the invoked rcu function decreases the global
      entry counter for that originator by one too and since the rcu invocation is
      likely to be postponed, the node will end up in first setting the counter to 0
      and then decreasing it one by one for each deleted client.
      
      This bug leads to having a wrong global entry counter for the related node, say
      X. Then when the node with the broken counter will answer to a TT_REQUEST on
      behalf of node X, it will create faulty TT_RESPONSE that will generate an
      unrecoverable situation on the node that asked for the full table recover.
      
      The non-recoverability is given by the fact that the node with the broken
      counter will keep answering on behalf of X because its knowledge about X's state
      (ttvn + tt_crc) is correct.
      
      To solve this problem the counter is not explicitly set to 0 anymore and the
      counter decrement is performed right before the invocation of call_rcu().
      Signed-off-by: default avatarAntonio Quartulli <ordex@autistici.org>
      8b8e4bc0
    • Marek Lindner's avatar
      batman-adv: only drop packets of known wifi clients · 5870adc6
      Marek Lindner authored
      bug introduced with 59b699cd
      
      If the source or destination mac address of an ethernet packet
      could not be found in the translation table the packet was
      dropped if AP isolation was turned on. This behavior would
      make it impossible to send broadcast packets over the mesh as
      the broadcast address will never enter the translation table.
      Signed-off-by: default avatarMarek Lindner <lindner_marek@yahoo.de>
      Acked-by: default avatarAntonio Quartulli <ordex@autistici.org>
      5870adc6
    • Yoshihiro Shimoda's avatar
      net: sh_eth: fix the condition to fix the cur_tx/dirty_rx · a18e08bd
      Yoshihiro Shimoda authored
      The following commit couldn't work if the RMCR is not set to 1.
      
      "net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens"
      commit id 79fba9f5
      
      If RMCR is not set, the controller will clear the EDRRR after it received
      a frame. In this case, the driver doesn't need to fix the value of
      cur_rx/dirty_rx. The driver only needs it when the controll detects
      receive descriptors are empty.
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Tested-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a18e08bd
    • françois romieu's avatar
      r8169: RxConfig hack for the 8168evl. · eb2dc35d
      françois romieu authored
      The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
      are very prone to NETDEV watchdog problems without this change. See
      https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.
      
      I don't know why it *works*. It's depressingly effective though.
      
      For the record:
      - the problem may go along IOMMU (AMD-Vi) errors but it really looks
        like a red herring.
      - the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
        the chipset now fetches several Rx descriptors at a time.
      - long ago the driver ignored the RX_MULTI_EN bit.
        e542a226 changed the RxConfig
        settings. Whatever the problem it's now labeled a regression.
      - Realtek's own driver can identify two different 8168evl devices
        (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
        sees one. It sucks.
      Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb2dc35d
    • Ming Lei's avatar
      usbnet: handle remote wakeup asap · 65841fd5
      Ming Lei authored
      If usbnet is resumed by remote wakeup, generally there are
      some packets comming to be handled, so allocate and submit
      rx URBs in usbnet_resume to avoid delays introduced by tasklet.
      Otherwise, usbnet may have been runtime suspended before the
      usbnet_bh is executed to schedule Rx URBs.
      
      Without the patch, usbnet can't recieve any packets from peer
      in runtime suspend state if runtime PM is enabled and
      autosuspend_delay is set as zero.
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65841fd5
    • Ming Lei's avatar
      usbnet: decrease suspend count if returning -EBUSY for runtime suspend · 5eeb3132
      Ming Lei authored
      This patch decreases dev->suspend_count in the -EBUSY failure path
      of usbnet_suspend. Without the change, the later runtime suspend
      will do nothing except for increasing dev->suspend_count.
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5eeb3132
    • Ming Lei's avatar
      usbnet: clear OPEN flag in failure path · fb13c47b
      Ming Lei authored
      Without clearing OPEN flag in failure path, runtime or system resume
      may submit interrupt/rx URB and start tx queue mistakenly on a
      interface in DOWN state.
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb13c47b
    • Bjørn Mork's avatar
      net: qmi_wwan: fix Gobi device probing · b9f90eb2
      Bjørn Mork authored
      Ignoring interfaces with additional descriptors is not a reliable
      method for locating the correct interface on Gobi devices.  There
      is at least one device where this method fails:
      https://bbs.archlinux.org/viewtopic.php?id=143506
      
      The result is that the AT command port (interface #2) is hidden
      from qcserial, preventing traditional serial modem usage:
      
      [   15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
      [   15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
      [   15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
      [   15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
      [   15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
      [   15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
      [   15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
      [   15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1
      
      Use static interface numbers taken from the interface map in
      qcserial for all Gobi devices instead:
      
      	Gobi 1K USB layout:
      	0: serial port (doesn't respond)
      	1: serial port (doesn't respond)
      	2: AT-capable modem port
      	3: QMI/net
      
      	Gobi 2K+ USB layout:
      	0: QMI/net
      	1: DM/DIAG (use libqcdm from ModemManager for communication)
      	2: AT-capable modem port
      	3: NMEA
      
      This should be more reliable over all, and will also prevent the
      noisy "probe failed" messages.  The whitelisting logic is expected
      to be replaced by direct interface number matching in 3.6.
      Reported-by: default avatarHeinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
      Cc: <stable@vger.kernel.org> # v3.4: 00001880 USB: qmi_wwan: Make forced int 4 whitelist generic
      Cc: <stable@vger.kernel.org> # v3.4: f7142e6c USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
      Cc: <stable@vger.kernel.org> # v3.4
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9f90eb2
  5. 22 Jun, 2012 1 commit
  6. 20 Jun, 2012 9 commits
  7. 19 Jun, 2012 5 commits