1. 22 5月, 2015 16 次提交
    • J
      sfc: Initialise MCDI buffers to 0 on declaration. · aa09a3da
      Jon Cooper 提交于
      In order to avoid MC bugs the flags field needs to be set to 0.
      Instead of explicitly clearing out the flags individually, a
      better way to do this is to memset the MCDI_BUF to 0.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa09a3da
    • D
      sfc: Enable a VF to get its own MAC address · 0d5e0fbb
      Daniel Pieczko 提交于
      A VF's MAC address is set by its parent PF and added to its vport.
      To get this MAC address, the VF must use MC_CMD_ VPORT_GET_MAC_ADDRESSES.
      In the current scheme, a VF's vport should only have one MAC address,
      so warn if this is not the case.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d5e0fbb
    • E
      sfc: protect filter table against use-after-free · 0d322413
      Edward Cree 提交于
      If MCDI timeouts are encountered during efx_ef10_filter_table_remove(),
      an FLR will be queued, but efx->filter_state will still be kfree()d.
      The queued FLR will then call efx_ef10_filter_table_restore(), which
      will try to use efx->filter_state. This previously caused a panic.
      This patch adds an rwsem to protect the existence of efx->filter_state,
      separately from the spinlock protecting its contents.  Users which can
      race against efx_ef10_filter_table_remove() should down_read this rwsem.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d322413
    • S
      sfc: Store the efx_nic struct of the current VF in the VF data struct · f1122a34
      Shradha Shah 提交于
      Initialised in efx_probe_vf and removal is dealt with in
      efx_ef10_remove.
      
      vf->efx is needed in future patches to change the MAC address
      of the VF via the parent PF, while the driver is bound to the
      VF.
      Example: ip link set dev vf NUM mac LLADDR
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1122a34
    • S
      sfc: save old MAC address in case sriov_mac_address_changed fails · cfc77c2f
      Shradha Shah 提交于
      Otherwise the PF and VF can disagree on the VF's MAC address and
      this leads to strange behaviour, up to and including kernel panics.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfc77c2f
    • S
      sfc: Store vf_index in nic_data for Ef10. · 88a37de6
      Shradha Shah 提交于
      Added function efx_ef10_get_vf_index to store the vf_index
      in nic_data during probe
      
      vf_index is needed in future patches to access a particular
      VF in the VF data structure.
      
      Moved efx_ef10_probe_pf and efx_ef10_probe_vf in order to
      used efx_ef10_remove
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88a37de6
    • S
      sfc: MC_CMD_SET_MAC can only be called by the link control Function · 862f894c
      Shradha Shah 提交于
      MC_CMD_SET_MAC is privileged and can only by called by the link
      control function.
      
      This patch adds efx_ef10_mac_reconfigure_vf which avoids the call
      to MC_CMD_SET_MAC by the Virtual function
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      862f894c
    • S
      af6a074d
    • S
      sfc: Add permissions to MCDI commands · 75122ec8
      Shradha Shah 提交于
      There is one primary function per adaptor, one link control function
      per port and the rest as categorised as general.
      
      This patch adds privileges to the MCDI commands based on which
      functions are allowed to call them.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75122ec8
    • V
      stmmac: replace open coded __netdev_alloc_skb_ip_align() with actual call · 4ec49a37
      Vineet Gupta 提交于
      This also matches with the sibling call netdev_alloc_skb_ip_align() made in
      rx fast path.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ec49a37
    • J
      qlge: Move jiffies_to_usecs immediately before loop · 3f6e785f
      Joe Perches 提交于
      30 usecs (or really, 1 jiffy) can go by pretty fast.
      
      Move the set of the timeout immediately before the loop.
      
      Remove the unnecessary max(1ul, usecs_to_jiffies(30)) as
      usecs_to_jiffies with a non-zero constant is guaranteed
      to be non-zero.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f6e785f
    • S
      rocker: make rocker_port_internal_vlan_id_{get, put}() non-transactional · df6a2067
      Simon Horman 提交于
      The motivation for this is that rocker_port_internal_vlan_id_{get,put} appear
      to only partially implement the transaction model: memory allocation
      and freeing is transactional, but hash and bitmap manipulation is not.
      
      The latter could be fixed, however, as it is not currently exercised
      due to trans always being SWITCHDEV_TRANS_NONE it seems cleaner
      to make rocker_port_internal_vlan_id_get non-transactional.
      
      This problem was introduced by c4f20321 ("rocker: support
      prepare-commit transaction model").
      
      Found by inspection.
      I do not believe that this change should have any run-time effect.
      Acked-by: NScott Feldman <sfeldma@gmail.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df6a2067
    • S
      rocker: do not make neighbour entry changes when preparing transactions · 550ecc92
      Simon Horman 提交于
      rocker_port_ipv4_nh() and in turn rocker_port_ipv4_neigh() may be
      be called with trans == SWITCHDEV_TRANS_PREPARE and then
      trans == SWITCHDEV_TRANS_COMMIT from switchdev_port_obj_set() via
      fib_table_insert().
      
      The first time that rocker_port_ipv4_nh() is called, with
      trans == SWITCHDEV_TRANS_PREPARE, _rocker_neigh_add() adds a new entry to
      the neigh table.
      
      And the second time  rocker_port_ipv4_nh() is called, with
      trans == SWITCHDEV_TRANS_COMMIT, that entry is found. This causes
      rocker_port_ipv4_nh() to believe it is not adding an entry and thus it
      frees "entry", which is still present in rocker driver's neigh table.
      
      This problem does not appear to affect deletion as my analysis is that
      deletion is always performed with trans == SWITCHDEV_TRANS_NONE.
      
      For completeness _rocker_neigh_{add,del,prepare} are updated not to
      manipulate fib table entries if trans == SWITCHDEV_TRANS_PREPARE.
      
      Fixes: c4f20321 ("rocker: support prepare-commit transaction model")
      Reported-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: NScott Feldman <sfeldma@gmail.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      550ecc92
    • S
      rocker: do not modify fdb table in rocker_port_fdb() when preparing transactions · 42e94889
      Simon Horman 提交于
      rocker_port_fdb_flush() may be called be called with
      trans == SWITCHDEV_TRANS_PREPARE and then trans == SWITCHDEV_TRANS_COMMIT from
      switchdev_port_attr_set() via switchdev_port_obj_add().
      
      Adding the new entry to the FDB table when trans == SWITCHDEV_TRANS_PREPARE
      may result in a memory leak because when trans == SWITCHDEV_TRANS_PREPARE
      rocker_flow_tbl_bridge() will allocate memory when called via
      rocker_port_fdb_learn(). However, when trans == SWITCHDEV_TRANS_COMMIT
      the presence of the FDB entry in the FDB table causes
      rocker_port_fdb() to set the ROCKER_OP_FLAG_REFRESH flag which results
      in rocker_port_fdb_learn() skipping the call to rocker_flow_tbl_bridge()
      which would free the memory allocated by it when
      trans == SWITCHDEV_TRANS_PREPARE.
      
      ip link add br0 type bridge
      ip link set up dev eth0
      ip link set dev eth0 master br0
      bridge fdb add 52:54:00:12:35:08 dev eth0
      bridge fdb add 52:54:00:12:35:09 dev eth0
      [    2.600730] ------------[ cut here ]------------
      [    2.601002] kernel BUG at drivers/net/ethernet/rocker/rocker.c:4369!
      [    2.601373] invalid opcode: 0000 [#1] SMP
      [    2.601963] Modules linked in:
      [    2.602355] CPU: 0 PID: 64 Comm: bridge Not tainted 4.1.0-rc3-01048-g6d0f50c50211-dirty #1075
      [    2.602721] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.0-0-g4c59f5d-20150219_092859-nilsson.home.kraxel.org 04/01/2014
      [    2.602721] task: ffff880019facef0 ti: ffff88001f96c000 task.ti: ffff88001f96c000
      [    2.602721] RIP: 0010:[<ffffffff811f1470>]  [<ffffffff811f1470>] rocker_port_obj_add+0x150/0x160
      [    2.602721] RSP: 0018:ffff88001f96fa98  EFLAGS: 00000212
      [    2.602721] RAX: ffff880019d4fa68 RBX: ffff88001f96fb18 RCX: 0000000000000000
      [    2.602721] RDX: ffff880019d4f000 RSI: ffff88001f96fb18 RDI: ffff880019d4f000
      [    2.602721] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff88001f904620
      [    2.602721] R10: ffff88001f96fb60 R11: ffff880019e9d100 R12: ffff88001f96fb18
      [    2.602721] R13: ffff880019d4f680 R14: ffff88001f904610 R15: ffff8800198f7b80
      [    2.602721] FS:  00007f3eee917700(0000) GS:ffff88001b000000(0000) knlGS:0000000000000000
      [    2.602721] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    2.602721] CR2: 00007f3eee4a15cb CR3: 000000001f933000 CR4: 00000000000006b0
      [    2.602721] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    2.602721] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
      [    2.602721] Stack:
      [    2.602721]  0000000000000000 ffff88001f96fb18 ffff880019d4f000 ffff88001f96fb18
      [    2.602721]  ffff880019d4f000 ffffffff81332105 ffff88001f96fb50 ffffffff814464c0
      [    2.602721]  ffff88001f96fb18 ffff88001f904600 ffff880019d4f000 ffffffff813326e5
      [    2.602721] Call Trace:
      [    2.602721]  [<ffffffff81332105>] ? __switchdev_port_obj_add+0x25/0x90
      [    2.602721]  [<ffffffff813326e5>] ? switchdev_port_obj_add+0x25/0xc0
      [    2.602721]  [<ffffffff813327b1>] ? switchdev_port_fdb_add+0x31/0x40
      [    2.602721]  [<ffffffff8123911f>] ? rtnl_fdb_add+0xff/0x1e0
      [    2.602721]  [<ffffffff81237d8e>] ? rtnetlink_rcv_msg+0x7e/0x250
      [    2.602721]  [<ffffffff8121d1ce>] ? __skb_recv_datagram+0xfe/0x4b0
      [    2.602721]  [<ffffffff81237d10>] ? rtnetlink_rcv+0x30/0x30
      [    2.602721]  [<ffffffff81247958>] ? netlink_rcv_skb+0xa8/0xd0
      [    2.602721]  [<ffffffff81237cff>] ? rtnetlink_rcv+0x1f/0x30
      [    2.602721]  [<ffffffff81247220>] ? netlink_unicast+0x150/0x200
      [    2.602721]  [<ffffffff81247714>] ? netlink_sendmsg+0x374/0x3e0
      [    2.602721]  [<ffffffff8120f8df>] ? sock_sendmsg+0xf/0x30
      [    2.602721]  [<ffffffff8120ffd3>] ? ___sys_sendmsg+0x1f3/0x200
      [    2.602721]  [<ffffffff812100e5>] ? ___sys_recvmsg+0x105/0x140
      [    2.602721]  [<ffffffff810a36f0>] ? SyS_readahead+0x90/0x90
      [    2.602721]  [<ffffffff81098dfd>] ? filemap_map_pages+0x1ed/0x210
      [    2.602721]  [<ffffffff810b77fc>] ? handle_mm_fault+0x5fc/0xe50
      [    2.602721]  [<ffffffff81210ef9>] ? __sys_sendmsg+0x39/0x70
      [    2.602721]  [<ffffffff8133ce17>] ? system_call_fastpath+0x12/0x6a
      [    2.602721] Code: b7 8f a0 06 00 00 48 83 bf 88 06 00 00 00 74 1d 48 83 c4 08 89 ee 4c 89 ef 5b 5d 41 5c 41 5d 0f b7 c9 45 31 c0 e9 51 db ff ff 90 <0f> 0b b8 ea ff ff ff e9 cf fe ff ff 0f 1f 40 00 41 57 41 56 b9
      [    2.602721] RIP  [<ffffffff811f1470>] rocker_port_obj_add+0x150/0x160
      [    2.602721]  RSP <ffff88001f96fa98>
      [    2.615848] ---[ end trace 4f7b4f1c98077108 ]---
      
      The above is resolved by not adding the new FDB entry to the FDB table
      if trans == SWITCHDEV_TRANS_PREPARE.
      
      For symmetry this patch also skips deleting FDB entries from the FDB
      table trans == SWITCHDEV_TRANS_PREPARE. However, my analysis is that
      this never occurs as trans is always SWITCHDEV_TRANS_NONE when removing
      FDB entries.
      
      Fixes: c4f20321 ("rocker: support prepare-commit transaction model")
      Acked-by: NScott Feldman <sfeldma@gmail.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42e94889
    • S
      rocker: do not delete fdb entries in rocker_port_fdb_flush() when preparing transactions · 3098ac39
      Simon Horman 提交于
      rocker_port_fdb_flush() is called by rocker_port_stp_update() which in
      turn may be called with trans == SWITCHDEV_TRANS_PREPARE and then
      trans == SWITCHDEV_TRANS_COMMIT from switchdev_port_attr_set() via
      br_set_state().
      
      When rocker_port_fdb_flush() is called with trans == SWITCHDEV_TRANS_PREPARE
      it calls rocker_port_fdb_learn() for each entry in the FDB table which in
      turn calls rocker_flow_tbl_bridge() which will allocate memory using
      rocker_port_kzalloc(). rocker_port_fdb_learn() will then remove the entry
      from the FDB table.
      
      Then when rocker_port_fdb_learn() is called with
      trans == SWITCHDEV_TRANS_PREPARE no calls are made to rocker_port_fdb_learn()
      because there are no longer any entries present in the FDB table. Thus the
      memory previously allocated by rocker_port_fdb_learn() is leaked resulting
      in the kernel BUG() below.
      
      Furthermore, it looks like the driver ends up with an incorrect view of the
      fdb table as the FDB entries are purged from the driver's table but not the
      hardware's table.
      
      ip link add br0 type bridge
      ip link set up dev eth0
      sleep 1
      ip link set dev eth0 master br0
      [    3.704360] ------------[ cut here ]------------
      [    3.704611] kernel BUG at drivers/net/ethernet/rocker/rocker.c:4289!
      [    3.704962] invalid opcode: 0000 [#1] SMP
      [    3.705537] Modules linked in:
      [    3.705919] CPU: 0 PID: 63 Comm: ip Not tainted 4.1.0-rc3-01046-gb9fbe709 #1044
      [    3.706191] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.0-0-g4c59f5d-20150219_092859-nilsson.home.kraxel.org 04/01/2014
      [    3.706820] task: ffff880019f70150 ti: ffff88001f92c000 task.ti: ffff88001f92c000
      [    3.707138] RIP: 0010:[<ffffffff811f0080>]  [<ffffffff811f0080>] rocker_port_attr_set+0xe0/0xf0
      [    3.707990] RSP: 0018:ffff88001f92f808  EFLAGS: 00000212
      [    3.708200] RAX: ffff880019d4fa68 RBX: ffff880019d4f000 RCX: 0000000000000000
      [    3.708471] RDX: 000000000000000c RSI: ffff88001f92f890 RDI: ffff880019d4f680
      [    3.708740] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000004
      [    3.708999] R10: ffff880000034024 R11: 0000000000000000 R12: ffff88001f92f890
      [    3.709276] R13: ffff88001f8f1c00 R14: 000000000000000b R15: 0000000000000000
      [    3.709303] FS:  00007f8ab66bd700(0000) GS:ffff88001b000000(0000) knlGS:0000000000000000
      [    3.709303] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    3.709303] CR2: 0000000000654988 CR3: 000000001f8f3000 CR4: 00000000000006b0
      [    3.709303] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    3.709303] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
      [    3.709303] Stack:
      [    3.709303]  ffff88001f8f1c00 000000000000000b ffff88001f92f890 ffff880019d4f000
      [    3.709303]  ffff88001f92f890 ffffffff813332f5 ffff88001f92f880 0000000000000000
      [    3.709303]  ffff88001f92f890 0000000000000001 ffff880019d4f000 ffffffff81333627
      [    3.709303] Call Trace:
      [    3.709303]  [<ffffffff813332f5>] ? __switchdev_port_attr_set+0x25/0x90
      [    3.709303]  [<ffffffff81333627>] ? switchdev_port_attr_set+0x27/0x120
      [    3.709303]  [<ffffffff81318e86>] ? br_set_state+0x36/0x50
      [    3.709303]  [<ffffffff8131795c>] ? br_add_if+0x37c/0x400
      [    3.709303]  [<ffffffff81238ce1>] ? do_setlink+0x7e1/0x800
      [    3.709303]  [<ffffffff8111f980>] ? radix_tree_lookup_slot+0x10/0x30
      [    3.709303]  [<ffffffff81136fba>] ? nla_parse+0xaa/0x110
      [    3.709303]  [<ffffffff81239c98>] ? rtnl_newlink+0x548/0x870
      [    3.709303]  [<ffffffff8111f900>] ? __radix_tree_lookup+0x40/0xb0
      [    3.709303]  [<ffffffff81136f3e>] ? nla_parse+0x2e/0x110
      [    3.709303]  [<ffffffff81237d7e>] ? rtnetlink_rcv_msg+0x7e/0x250
      [    3.709303]  [<ffffffff8121d1be>] ? __skb_recv_datagram+0xfe/0x4b0
      [    3.709303]  [<ffffffff81237d00>] ? rtnetlink_rcv+0x30/0x30
      [    3.709303]  [<ffffffff81247948>] ? netlink_rcv_skb+0xa8/0xd0
      [    3.709303]  [<ffffffff81237cef>] ? rtnetlink_rcv+0x1f/0x30
      [    3.709303]  [<ffffffff81247210>] ? netlink_unicast+0x150/0x200
      [    3.709303]  [<ffffffff81247704>] ? netlink_sendmsg+0x374/0x3e0
      [    3.709303]  [<ffffffff8120f8cf>] ? sock_sendmsg+0xf/0x30
      [    3.709303]  [<ffffffff8120ffc3>] ? ___sys_sendmsg+0x1f3/0x200
      [    3.709303]  [<ffffffff812100d5>] ? ___sys_recvmsg+0x105/0x140
      [    3.709303]  [<ffffffff812228d9>] ? dev_get_by_name_rcu+0x69/0x90
      [    3.709303]  [<ffffffff812228d9>] ? dev_get_by_name_rcu+0x69/0x90
      [    3.709303]  [<ffffffff81217b7d>] ? skb_dequeue+0x4d/0x60
      [    3.709303]  [<ffffffff81217bb0>] ? skb_queue_purge+0x20/0x30
      [    3.709303]  [<ffffffff810ebdcf>] ? __inode_wait_for_writeback+0x5f/0xb0
      [    3.709303]  [<ffffffff810648b0>] ? autoremove_wake_function+0x30/0x30
      [    3.709303]  [<ffffffff81210ee9>] ? __sys_sendmsg+0x39/0x70
      [    3.709303]  [<ffffffff8133e097>] ? system_call_fastpath+0x12/0x6a
      [    3.709303] Code: bb 90 06 00 00 48 c7 04 24 00 00 00 00 45 31 c9 45 31 c0 48 c7 c1 c0 b7 1e 81 89 ea e8 da da ff ff eb 95 0f 1f 84 00 00 00 00 00 <0f> 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 fe 15 75
      [    3.709303] RIP  [<ffffffff811f0080>] rocker_port_attr_set+0xe0/0xf0
      [    3.709303]  RSP <ffff88001f92f808>
      [    3.721409] ---[ end trace b7481fcb7cb032aa ]---
      Segmentation fault
      
      Fixes: c4f20321 ("rocker: support prepare-commit transaction model")
      Acked-by: NScott Feldman <sfeldma@gmail.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3098ac39
    • J
      spider_net: Use DECLARE_BITMAP · e26cc7ff
      Joe Perches 提交于
      Use the generic mechanism to declare a bitmap instead of unsigned long.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e26cc7ff
  2. 20 5月, 2015 3 次提交
  3. 19 5月, 2015 1 次提交
  4. 18 5月, 2015 1 次提交
  5. 16 5月, 2015 18 次提交
  6. 15 5月, 2015 1 次提交