1. 06 9月, 2014 3 次提交
    • A
      cnic : Cleanup CONFIG_IPV6 & VLAN check · c99d667e
      Anish Bhatt 提交于
      The cnic module needs to ensure that if ipv6 support is compiled as a module,
      then the cnic module cannot be compiled as built-in as it depends on ipv6.
      Made this check cleaner via Kconfig
      
      Use simpler IS_ENABLED for CONFIG_VLAN_8021Q check
      Signed-off-by: NAnish Bhatt <anish@chelsio.com>
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c99d667e
    • Y
      bnx2x: Fix link problems for 1G SFP RJ45 module · 6e9e5644
      Yaniv Rosner 提交于
      When 1G SFP RJ45 module is detected, driver must reset the Tx laser
      in order to prevent link issues. As part of change, the link_attr_sync
      was relocated from vars to params.
      Signed-off-by: NYaniv Rosner <Yaniv.Rosner@qlogic.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e9e5644
    • N
      3c59x: avoid panic in boomerang_start_xmit when finding page address: · 98ea232c
      Neil Horman 提交于
      This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):
      
      BUG: unable to handle kernel paging request at 00800000
      IP: [<c04107b5>] nommu_map_page+0x15/0x110
      *pdpt = 000000003454f001 *pde = 000000003f03d067
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/cpu/online
      Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs p4_clockmod
      ipv6 ppdev parport_pc parport microcode iTCO_wdt iTCO_vendor_support 3c59x mii
      dcdbas serio_raw snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device
      snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 sg lpc_ich mfd_core ext4
      jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix
      radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash
      dm_log dm_mod [last unloaded: mperf]
      
      Pid: 4219, comm: nfsd Not tainted 2.6.32-491.el6.i686 #1 Dell Computer
      Corporation OptiPlex GX240               /OptiPlex GX240
      EIP: 0060:[<c04107b5>] EFLAGS: 00010246 CPU: 0
      EIP is at nommu_map_page+0x15/0x110
      EAX: 00000000 EBX: c0a83480 ECX: 00000000 EDX: 00800000
      ESI: 00000000 EDI: f70e7860 EBP: e2d09b54 ESP: e2d09b24
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process nfsd (pid: 4219, ti=e2d08000 task=e2ceaaa0 task.ti=e2d08000)
      Stack:
       00000056 00000000 0000000e c65efd38 00000020 00000296 00000206 00000206
      <0> c050c850 c0a83480 e2cef154 00000001 e2d09ba8 f8fcd585 00000510 00000001
      <0> 00000000 00000000 f5172200 f8fdac00 0039ef8c f5277020 f70e7860 00000510
      Call Trace:
       [<c050c850>] ? page_address+0xd0/0xe0
       [<f8fcd585>] ? boomerang_start_xmit+0x3b5/0x520 [3c59x]
       [<c07b2975>] ? dev_hard_start_xmit+0xe5/0x400
       [<f9182b00>] ? ip6_output_finish+0x0/0xf0 [ipv6]
       [<c07ca053>] ? sch_direct_xmit+0x113/0x180
       [<c07d5588>] ? nf_hook_slow+0x68/0x120
       [<c07b2ea5>] ? dev_queue_xmit+0x1b5/0x290
       [<f9182b6d>] ? ip6_output_finish+0x6d/0xf0 [ipv6]
       [<f9184cb8>] ? ip6_xmit+0x3e8/0x490 [ipv6]
       [<f91ab9f9>] ? inet6_csk_xmit+0x289/0x2f0 [ipv6]
       [<c07f6451>] ? tcp_transmit_skb+0x431/0x7f0
       [<c07a403f>] ? __alloc_skb+0x4f/0x140
       [<c07f85a2>] ? tcp_write_xmit+0x1c2/0xa50
       [<c07f90b1>] ? __tcp_push_pending_frames+0x31/0xe0
       [<c07ea47a>] ? tcp_sendpage+0x44a/0x4b0
       [<c07ea030>] ? tcp_sendpage+0x0/0x4b0
       [<c079be1e>] ? kernel_sendpage+0x4e/0x90
       [<f8457bb9>] ? svc_send_common+0xc9/0x120 [sunrpc]
       [<f8457c85>] ? svc_sendto+0x75/0x1f0 [sunrpc]
       [<c060d0d9>] ? _atomic_dec_and_lock+0x59/0x90
       [<f87d55d0>] ? nfs3svc_encode_readres+0x0/0xc0 [nfsd]
       [<f845876d>] ? svc_authorise+0x2d/0x40 [sunrpc]
       [<f87d4410>] ? nfs3svc_release_fhandle+0x0/0x10 [nfsd]
       [<f8455721>] ? svc_process_common+0xf1/0x5a0 [sunrpc]
       [<f8457e86>] ? svc_tcp_sendto+0x36/0xa0 [sunrpc]
       [<f8461778>] ? svc_send+0x98/0xd0 [sunrpc]
       [<f87c698c>] ? nfsd+0xac/0x140 [nfsd]
       [<c04470e0>] ? complete+0x40/0x60
       [<f87c68e0>] ? nfsd+0x0/0x140 [nfsd]
       [<c04802ac>] ? kthread+0x7c/0xa0
       [<c0480230>] ? kthread+0x0/0xa0
       [<c0409f9f>] ? kernel_thread_helper+0x7/0x10
      Code: 8d b6 00 00 00 00 eb f8 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
      83 ec 30 89 75 f8 31 f6 89 7d fc 89 c7 89 c8 89 5d f4 <8b> 1a 8b 4d 08 c1 eb 19
      c1 e3 04 8b 9b c0 29 c7 c0 83 e3 fc 29
      
      But the problem seems to still exist upstream.  It seems on 32 bit kernels
      page_address() can reutrn a NULL value in some circumstances, and the
      pci_map_single api isn't prepared to handle that (on this system it results in a
      bogus pointer deference in nommu_map_page.
      
      The fix is pretty easy, if we convert the 3c59x driver to use the more
      convieient skb_frag_dma_map api we don't need to find the virtual address of the
      page at all, and page gets mapped to the hardware properly.  Verified to fix the
      problem as described by the reporter.
      
      Applies to the net tree
      
      Change Notes:
      
      v2) Converted PCI_DMA_TODEVICE to DMA_TO_DEVICE.  Thanks Dave!
      
      v3) Actually Run git commit after making changes to v2 :)
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: klassert@mathematik.tu-chemnitz.de
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98ea232c
  2. 03 9月, 2014 6 次提交
  3. 02 9月, 2014 13 次提交
  4. 01 9月, 2014 4 次提交
  5. 30 8月, 2014 5 次提交
  6. 26 8月, 2014 9 次提交
    • D
      mvneta: Add missing if_vlan.h include. · 2d39d120
      David S. Miller 提交于
      drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_skb_tx_csum':
      drivers/net/ethernet/marvell/mvneta.c:1374:3: error: implicit declaration of function 'vlan_get_protocol' [-Werror=implicit-function-declaration]
         __be16 l3_proto = vlan_get_protocol(skb);
         ^
      Reporeted-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d39d120
    • V
      qlge: Fix TSO for non-accelerated vlan traffic · 1ee1cfe7
      Vlad Yasevich 提交于
      This device claims TSO support for vlans.  It also allows a user to
      control vlan acceleration offloading.  As such, it is possible to turn
      off vlan acceleration and configure a vlan which will continue to send
      TSO traffic.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO information.
      This results in corrupted frames sent on the wire.
      
      This patch extracts the protocol value correctly by using a
      vlan_get_protocol() helper and corrects corrupt TSO frames.
      
      CC: Shahed Shaikh <shahed.shaikh@qlogic.com>
      CC: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
      CC: Ron Mercer <ron.mercer@qlogic.com>
      CC: linux-driver@qlogic.com
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ee1cfe7
    • V
      mvneta: Fix TSO and checksum for non-acceleration vlan traffic · 817dbfa5
      Vlad Yasevich 提交于
      This driver doesn't appear to support vlan acceleration at
      all.  However, it does claim to support TSO and IP checksums
      for vlan devices.  Thus any configured vlan device would
      end up passing down partial checksums or TSO frames.
      
      The driver also uses the value from skb->protocol to
      determine TSO and checksum offload information, but assumes
      that skb->protocol holds the l3 protocol information.
      As a result, vlan traffic with partial checksums or TSO
      will fail those checks and TSO will not happen.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      817dbfa5
    • V
      i40evf: Fix TSO and hw checksums for non-accelerated vlan packets. · a12c4158
      Vlad Yasevich 提交于
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO and hw checksums.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO and checksum information.
      This results in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a12c4158
    • V
      i40e: Fix TSO and hw checksums for non-accelerated vlan packets. · 3d34dd03
      Vlad Yasevich 提交于
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO and hw checksums.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO and checksum information.
      This results in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d34dd03
    • V
      ehea: Fix TSO and hw checksums with non-accelerated vlan packets. · be1d1486
      Vlad Yasevich 提交于
      The driver claims that it can do TSO and IP checksums on vlan
      devices and also allows user to control vlan acceleration offloading.
      This makes it possible to push traffic to this driver that has TSO or
      partial checksums set, but also have a non-accelearted vlan
      header.  In this case, the driver will fail to correctly
      identify such traffic and will not correctly perform
      segmentation and checksum calculation.
      
      Fix this by using vlan_get_protocol() helper instead of
      assuming skb->protocol always has this information.
      
      CC: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be1d1486
    • V
      bna: Support TSO and partial checksum with non-accelerated vlans. · 1c53730a
      Vlad Yasevich 提交于
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO information.  This results
      in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      CC: Rasesh Mody <rmody@brocade.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c53730a
    • V
      e1000: Fix TSO for non-accelerated vlan traffic · 06f4d033
      Vlad Yasevich 提交于
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO and checksum information.
      This will results in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      for non-accelerated traffic.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06f4d033
    • V
      e1000e: Fix TSO with non-accelerated vlans · 47ccd1ed
      Vlad Yasevich 提交于
      This device claims  TSO support for vlans.  It also allows a
      user to control vlan acceleration offloading.  As such, it is
      possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO information.  This results
      in corrupted frames sent on the wire.  Corruptions include
      incorrect IP total length and invalid IP checksum.
      
      This patch extract the protocol value correctly and corrects TSO
      for non-accelerated traffic.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      47ccd1ed