1. 24 11月, 2014 2 次提交
    • D
      ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe · b5b2ffc0
      Daniel Borkmann 提交于
      While working on a different issue, I noticed an annoying use
      after free bug on my machine when unloading the ixgbe driver:
      
      [ 8642.318797] ixgbe 0000:02:00.1: removed PHC on p2p2
      [ 8642.742716] ixgbe 0000:02:00.1: complete
      [ 8642.743784] BUG: unable to handle kernel paging request at ffff8807d3740a90
      [ 8642.744828] IP: [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [ 8642.745886] PGD 20c6067 PUD 81c1f6067 PMD 81c15a067 PTE 80000007d3740060
      [ 8642.746956] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [ 8642.748039] Modules linked in: [...]
      [ 8642.752929] CPU: 1 PID: 1225 Comm: rmmod Not tainted 3.18.0-rc2+ #49
      [ 8642.754203] Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 1.1b 11/01/2013
      [ 8642.755505] task: ffff8807e34d3fe0 ti: ffff8807b7204000 task.ti: ffff8807b7204000
      [ 8642.756831] RIP: 0010:[<ffffffffa01c77dc>]  [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [...]
      [ 8642.774335] Stack:
      [ 8642.775805]  ffff8807ee824098 ffff8807ee824098 ffffffffa01f3000 ffff8807ee824000
      [ 8642.777326]  ffff8807b7207e18 ffffffff8137720f ffff8807ee824098 ffff8807ee824098
      [ 8642.778848]  ffffffffa01f3068 ffff8807ee8240f8 ffff8807b7207e38 ffffffff8144180f
      [ 8642.780365] Call Trace:
      [ 8642.781869]  [<ffffffff8137720f>] pci_device_remove+0x3f/0xc0
      [ 8642.783395]  [<ffffffff8144180f>] __device_release_driver+0x7f/0xf0
      [ 8642.784876]  [<ffffffff814421f8>] driver_detach+0xb8/0xc0
      [ 8642.786352]  [<ffffffff814414a9>] bus_remove_driver+0x59/0xe0
      [ 8642.787783]  [<ffffffff814429d0>] driver_unregister+0x30/0x70
      [ 8642.789202]  [<ffffffff81375c65>] pci_unregister_driver+0x25/0xa0
      [ 8642.790657]  [<ffffffffa01eb38e>] ixgbe_exit_module+0x1c/0xc8e [ixgbe]
      [ 8642.792064]  [<ffffffff810f93a2>] SyS_delete_module+0x132/0x1c0
      [ 8642.793450]  [<ffffffff81012c61>] ? do_notify_resume+0x61/0xa0
      [ 8642.794837]  [<ffffffff816d2029>] system_call_fastpath+0x12/0x17
      
      The issue is that test_and_set_bit() done on adapter->state is being
      performed *after* the netdevice has been freed via free_netdev().
      
      When netdev is being allocated on initialization time, it allocates
      a private area, here struct ixgbe_adapter, that resides after the
      net_device structure. In ixgbe_probe(), the device init routine,
      we set up the adapter after alloc_etherdev_mq() on the private area
      and add a reference for the pci_dev as well via pci_set_drvdata().
      
      Both in the error path of ixgbe_probe(), but also on module unload
      when ixgbe_remove() is being called, commit 41c62843 ("ixgbe:
      Fix rcu warnings induced by LER") accesses adapter after free_netdev().
      The patch stores the result in a bool and thus fixes above oops on my
      side.
      
      Fixes: 41c62843 ("ixgbe: Fix rcu warnings induced by LER")
      Cc: stable <stable@vger.kernel.org>
      Cc: Mark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5b2ffc0
    • V
      ixgbe: Correctly disable VLAN filter in promiscuous mode · 4556dc59
      Vlad Yasevich 提交于
      IXGBE adapter seems to require that VLAN filtering be enabled if
      VMDQ or SRIOV are enabled.  When those functions are disabled,
      VLAN filtering may be disabled in promiscuous mode.
      
      Prior to commit a9b8943e ("ixgbe: remove vlan_filter_disable
      and enable functions")
      
      The logic was correct.  However, after the commit the logic
      got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
      is disabled.
      
      This patch changes the condition to enable hw vlan filtered
      when VMDQ or SRIOV is enabled.
      
      Fixes: a9b8943e ("ixgbe: remove vlan_filter_disable and enable functions")
      Cc: stable <stable@vger.kernel.org>
      CC: Jacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4556dc59
  2. 30 10月, 2014 1 次提交
  3. 11 10月, 2014 1 次提交
  4. 02 10月, 2014 2 次提交
  5. 18 9月, 2014 2 次提交
  6. 12 9月, 2014 2 次提交
  7. 06 9月, 2014 1 次提交
  8. 04 9月, 2014 3 次提交
    • J
      ixgbe: limit combined total of macvlan and SR-IOV VFs · aac2f1bf
      Jacob Keller 提交于
      Hardware has a limited number of pools available (64). Previously, no
      checks were in place to limit the number of accelerated macvlan devices
      based on the number of pools. Normally this would be ok, because there
      was already a limit for these well below the number of available pools.
      However, SR-IOV uses the very same pools. Therefor, we need to ensure
      that the total number of pools (number of VFs plus the number of non-VF
      pools in use for accelerated macvlans) does not exceed the number of
      pools available in hardware.
      
      This patch resolves a kernel NULL pointer dereference caused by the following commands:
      
      $modprobe ixgbe max_vfs=63
      
      $ethtool -K eth2 l2-fwd-offload on
      
      $ip link add link eth2 macvlan0 type macvlan
      
      $ip link set dev macvlan0 up
      
      [  992.950080] BUG: unable to handle kernel NULL pointer dereference at 0000000000000056
      [  992.951109] IP: [<ffffffffa003b71e>] ixgbe_disable_fwd_ring+0x1e/0xf0 [ixgbe]
      [  992.951684] PGD 22a80e067 PUD 232e9b067 PMD 0
      [  992.952389] Oops: 0000 [#1] SMP
      [  992.953014] Modules linked in: nfsd lockd nfs_acl exportfs auth_rpcgss oid_registry sunrpc bridge stp llc vhost_net macvtap macvlan vhost tun kvm_intel kvm ioatdma ixgbe mdio igb dca
      [  992.956042] CPU: 2 PID: 11928 Comm: ifconfig Not tainted 3.16.0-rc6-net-next-07-29-2014-FCoE+ #1
      [  992.956915] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.0003.041920141333 04/19/2014
      [  992.957791] task: ffff8804341c0000 ti: ffff8801d7dc8000 task.ti: ffff8801d7dc8000
      [  992.958660] RIP: 0010:[<ffffffffa003b71e>]  [<ffffffffa003b71e>] ixgbe_disable_fwd_ring+0x1e/0xf0 [ixgbe]
      [  992.959613] RSP: 0018:ffff8801d7dcbbb8  EFLAGS: 00010286
      [  992.960093] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
      [  992.960575] RDX: ffff880232eb7000 RSI: 0000000000000000 RDI: ffff88022dc05800
      [  992.961059] RBP: ffff8801d7dcbbd8 R08: 0000000000000000 R09: 0000000000000000
      [  992.961541] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88022ec20980
      [  992.962023] R13: ffff880232eb7000 R14: 0000000000000001 R15: 0000000000000001
      [  992.962508] FS:  00007fab264887a0(0000) GS:ffff880237640000(0000) knlGS:0000000000000000
      [  992.963378] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  992.963858] CR2: 0000000000000056 CR3: 000000022a939000 CR4: 00000000001427e0
      [  992.964340] Stack:
      [  992.964806]  ffff88022ec28840 ffff88022ec20980 ffff88022dc05800 ffff880232eb7000
      [  992.965976]  ffff8801d7dcbc28 ffffffffa003bae8 ffff8801d7dcbbe8 0000000000000400
      [  992.967147]  000000000000000d ffff88022ec20980 ffff88022ec20000 ffff88022dc05800
      [  992.968319] Call Trace:
      [  992.968795]  [<ffffffffa003bae8>] ixgbe_fwd_ring_up+0x88/0x280 [ixgbe]
      [  992.969284]  [<ffffffffa0041d83>] ixgbe_fwd_add+0x173/0x220 [ixgbe]
      [  992.969767]  [<ffffffffa015056c>] macvlan_open+0x1bc/0x230 [macvlan]
      [  992.970256]  [<ffffffff816b8de7>] __dev_open+0xd7/0x150
      [  992.970735]  [<ffffffff816b8bd7>] __dev_change_flags+0xa7/0x170
      [  992.971220]  [<ffffffff816b8ccb>] dev_change_flags+0x2b/0x70
      [  992.971703]  [<ffffffff817471b2>] devinet_ioctl+0x602/0x6d0
      [  992.972184]  [<ffffffff81748168>] inet_ioctl+0x78/0x90
      [  992.972666]  [<ffffffff816a143b>] sock_do_ioctl+0x2b/0x70
      [  992.973146]  [<ffffffff816a14ed>] sock_ioctl+0x6d/0x260
      [  992.973627]  [<ffffffff811ad3b4>] do_vfs_ioctl+0x84/0x540
      [  992.974109]  [<ffffffff811a4c81>] ? final_putname+0x21/0x50
      [  992.974593]  [<ffffffff818725d5>] ? sysret_check+0x22/0x5d
      [  992.975073]  [<ffffffff811ad901>] SyS_ioctl+0x91/0xa0
      [  992.975550]  [<ffffffff818725a9>] system_call_fastpath+0x16/0x1b
      [  992.976026] Code: ff 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 20 48 89 5d e8 4c 89 65 f0 48 89 f3 4c 89 6d f8 4c 8b a7 08 02 00 00 <44> 0f b6 6e 56 44 03 af 14 02 00 00 4c 89 e7 e8 5e f2 ff ff be
      [  992.982261] RIP  [<ffffffffa003b71e>] ixgbe_disable_fwd_ring+0x1e/0xf0 [ixgbe]
      [  992.983212]  RSP <ffff8801d7dcbbb8>
      [  992.983681] CR2: 0000000000000056
      [  992.984248] ---[ end trace 9f54802b5cc3638b ]---
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      aac2f1bf
    • E
      ixgbe: reset interface on link loss with pending Tx work from the VF · 07923c17
      Emil Tantilov 提交于
      ixgbe initiates a reset of the interface on link loss with pending Tx work
      in order to clear the rings.
      
      This patch extends the pending Tx work check to the VF interfaces with the
      same purpose.
      Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      07923c17
    • A
      ixgbe: Cleanup FDB handling code · bcfd3432
      Alexander Duyck 提交于
      This change makes it so that the behavior for FDB handling is consistent
      between both the SR-IOV and non-SR-IOV cases.  The main change here is that we
      perform bounds checking on the number of SR-IOV addresses regardless of if
      SR-IOV is enabled or not as we can only support a certain number of addresses
      in the hardware.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      bcfd3432
  9. 28 8月, 2014 1 次提交
  10. 26 8月, 2014 1 次提交
  11. 13 8月, 2014 1 次提交
  12. 26 7月, 2014 1 次提交
  13. 24 7月, 2014 4 次提交
  14. 04 6月, 2014 1 次提交
    • E
      ixgbe: fix detection of SFP+ capable interfaces · d9cd46cd
      Emil Tantilov 提交于
      In cases where the driver is loaded while there are no SFP+ modules in
      the cage the interface was not being detected as SFP capable. To account
      for this the driver called identify_sfp in ixgbe_get_settings to make
      sure the data is correct. However when there is no SFP+ module in the cage
      the driver waits for the I2C reads to time out which can take more than a
      second and will cause issues with tools (like net-snmp) that may poll
      for that information.
      
      This patch resolves the issue by identifying interfaces with no PHY
      type set as SFP capable which allows the driver to detect the SFP module
      when the interface is brought up. As result of this we can also remove the
      identify_sfp call from ixgbe_get_settings.
      
      v2: remove the 82599 specific check since we have 82598 devices that are SFP
      capable.
      Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d9cd46cd
  15. 27 5月, 2014 2 次提交
  16. 24 5月, 2014 1 次提交
    • S
      net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool. · ed616689
      Sucheta Chakraborty 提交于
      o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
        to have a bandwidth of at least this value.
        max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
        of up to this value.
      
      o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
        which takes 4 arguments:
        netdev, VF number, min_tx_rate, max_tx_rate
      
      o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler.
      
      o Drivers that currently implement ndo_set_vf_tx_rate should now call
        ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth
        greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet
        implemented by driver.
      
      o If user enters only one of either min_tx_rate or max_tx_rate, then,
        userland should read back the other value from driver and set both
        for IFLA_VF_RATE.
        Drivers that have not yet implemented IFLA_VF_RATE should always
        return min_tx_rate as 0 when read from ip tool.
      
      o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then
        IFLA_VF_RATE should override.
      
      o Idea is to have consistent display of rate values to user.
      
      o Usage example: -
      
        ./ip link set p4p1 vf 0 rate 900
      
        ./ip link show p4p1
        32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
        DEFAULT qlen 1000
          link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
          vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps
          vf 1 MAC f6:c6:7c:3f:3d:6c
          vf 2 MAC 56:32:43:98:d7:71
          vf 3 MAC d6:be:c3:b5:85:ff
          vf 4 MAC ee:a9:9a:1e:19:14
          vf 5 MAC 4a:d0:4c:07:52:18
          vf 6 MAC 3a:76:44:93:62:f9
          vf 7 MAC 82:e9:e7:e3:15:1a
      
        ./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200
      
        ./ip link show p4p1
        32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
        DEFAULT qlen 1000
          link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
          vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps,
          min_tx_rate 200Mbps
          vf 1 MAC f6:c6:7c:3f:3d:6c
          vf 2 MAC 56:32:43:98:d7:71
          vf 3 MAC d6:be:c3:b5:85:ff
          vf 4 MAC ee:a9:9a:1e:19:14
          vf 5 MAC 4a:d0:4c:07:52:18
          vf 6 MAC 3a:76:44:93:62:f9
          vf 7 MAC 82:e9:e7:e3:15:1a
      
        ./ip link set p4p1 vf 0 max_tx_rate 600 rate 300
      
        ./ip link show p4p1
        32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
        DEFAULT qlen 1000
          link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff
          vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps,
          min_tx_rate 200Mbps
          vf 1 MAC f6:c6:7c:3f:3d:6c
          vf 2 MAC 56:32:43:98:d7:71
          vf 3 MAC d6:be:c3:b5:85:ff
          vf 4 MAC ee:a9:9a:1e:19:14
          vf 5 MAC 4a:d0:4c:07:52:18
          vf 6 MAC 3a:76:44:93:62:f9
          vf 7 MAC 82:e9:e7:e3:15:1a
      Signed-off-by: NSucheta Chakraborty <sucheta.chakraborty@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed616689
  17. 23 5月, 2014 1 次提交
  18. 23 4月, 2014 5 次提交
  19. 19 4月, 2014 1 次提交
  20. 18 4月, 2014 1 次提交
  21. 11 4月, 2014 2 次提交
  22. 01 4月, 2014 3 次提交
  23. 20 3月, 2014 1 次提交