- 22 May, 2015 2 commits
-
-
Marcelo Ricardo Leitner authored
This patch tracks the total number of inbound and outbound segments on a TCP socket. One may use this number to have an idea on connection quality when compared against the retransmissions. RFC4898 named these : tcpEStatsPerfSegsIn and tcpEStatsPerfSegsOut These are a 32bit field each and can be fetched both from TCP_INFO getsockopt() if one has a handle on a TCP socket, or from inet_diag netlink facility (iproute2/ss patch will follow) Note that tp->segs_out was placed near tp->snd_nxt for good data locality and minimal performance impact, while tp->segs_in was placed near tp->bytes_received for the same reason. Join work with Eric Dumazet. Note that received SYN are accounted on the listener, but sent SYNACK are not accounted. Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
ip -6 addr add dead::1/128 dev eth0 sleep 5 ip -6 route add default via dead::1/128 -> fails ip -6 addr add dead::1/128 dev eth0 ip -6 route add default via dead::1/128 -> succeeds reason is that if (nonsensensical) route above is added, dead::1 is still subject to DAD, so the route lookup will pick eth0 as outdev due to the prefix route that is added before DAD work is started. Add explicit test that checks if nexthop gateway is a local address. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1167969Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 21 May, 2015 38 commits
-
-
David S. Miller authored
Joachim Eastwood says: ==================== stmmac: probe code refactoring and clean up part 1 This patch set refactor the code in stmmac_pci_probe and stmmac_pltfr_probe and moves the common bits into stmmac_dvr_probe. Along the way some clean- ups are applied to stmmac_pltfr_probe. The code has been tested on the LPC18xx platform. I am still working on more refactoring of the platform probe code, hence part 1, but I need some more time on this. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joachim Eastwood authored
Since the caller already check the presence of a of_node there is no need to repeat the check in stmmac_probe_config_dt. There is also no point in checking the return value of the of_match_device function since if there wasn't match in the first place we would never be in this function. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joachim Eastwood authored
Since stmmac_dvr_probe takes care of setting driver data and assign resources to the priv structure there is no need to access the priv structure from the other probe functions. This mean that this function can be changed into just return an int and thus simplifying the callers. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joachim Eastwood authored
Creat a struct that contain all the resources that needs to be assigned to the priv struct in stmmac_dvr_probe. This makes it possible to factor out more common code from the other probe functions and also use this struct to hold the resources as they are fetched. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joachim Eastwood authored
Move setting of driver data into stmmac_dvr_probe so the other probe functions don't have to. This will help to simplify the other probe functions later. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Eric Dumazet says: ==================== tcp: improve source port selection With increase of TCP sockets in hosts, we often hit limitations caused by port selection, due to randomization and poor strategy. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
inet_csk_get_port() randomization effort tends to spread sockets on all the available range (ip_local_port_range) This is unfortunate because SO_REUSEADDR sockets have less requirements than non SO_REUSEADDR ones. If an application uses SO_REUSEADDR hint, it is to try to allow source ports being shared. So instead of picking a random port number in ip_local_port_range, lets try first in first half of the range. This gives more chances to use upper half of the range for the sockets with strong requirements (not using SO_REUSEADDR) Note this patch does not add a new sysctl, and only changes the way we try to pick port number. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <mleitner@redhat.com> Cc: Flavio Leitner <fbl@redhat.com> Acked-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
We no longer need bsocket atomic counter, as inet_csk_get_port() calls bind_conflict() regardless of its value, after commit 2b05ad33 ("tcp: bind() fix autoselection to share ports") This patch removes overhead of maintaining this counter and double inet_csk_get_port() calls under pressure. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <mleitner@redhat.com> Cc: Flavio Leitner <fbl@redhat.com> Acked-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jason Baron authored
We currently rely on the setting of SOCK_NOSPACE in the write() path to ensure that we wake up any epoll edge trigger waiters when acks return to free space in the write queue. However, if we fail to allocate even a single skb in the write queue, we could end up waiting indefinitely. Fix this by explicitly issuing a wakeup when we detect the condition of an empty write queue and a return value of -EAGAIN. This allows userspace to re-try as we expect this to be a temporary failure. I've tested this approach by artificially making sk_stream_alloc_skb() return NULL periodically. In that case, epoll edge trigger waiters will hang indefinitely in epoll_wait() without this patch. Signed-off-by: Jason Baron <jbaron@akamai.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hariprasad Shenai says: ==================== cxgb4: Cleanup and update T4/T4 register ranges This series cleans and optimizes setup_memwin function and also updates T4/T5 adapter register ranges by removing incorrect register addresses This patch series has been created against net-next tree and includes patches on cxgb4 driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Remove some T4/T5 registers that were included incorrectly. Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shradha Shah says: ==================== sfc: Get/Set MAC address and ndo_[set/get]_vf_* entrypoint functions This is the second installment of patches towards supporting EF10 SRIOV. This patch series implements the ndo_get_vf_config, ndo_set_vf_mac, ndo_set_vf_vlan and ndo_set_vf_spoofcheck function callbacks for EF10. This patch series also introduces privileges for the MCDI commands based on which functions are allowed to call them, i.e. Link control or primary function. The patch series has been tested with and without CONFIG_SFC_SRIOV. The ndo function callbacks are tested using ip link. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
Add a set_mac_address() NIC-type function for EF10 only, and use this to set the MAC address on the vadaptor. For Siena and earlier, the MAC address continues to be set by MC_CMD_SET_MAC; this is still called on EF10, and including a MAC address in this command has no effect. The sriov_mac_address_changed() NIC-type function is no longer needed on EF10, but it is needed for Siena where it is used to update the peer address of the PF for VFDI. Change this to use the new set_mac_address function pointer. efx_ef10_sriov_mac_address_changed() is no longer called, as VFs will try to change the MAC address on their vadaptor rather than trying to change to the context of the PF to alter the vport. When a VF is running in direct passthrough mode with MAC spoofing enabled, it will be able to change the MAC address on its vadaptor. In this case, there is a link to the PF, so find the correct VF in its ef10_vf array and update the MAC address. ndo_set_mac_address() can be called during driver unload while bonding, and in this case the device has already been stopped, so don't call efx_net_open() to restart it after reconfiguration. efx->port_enabled is set to false in efx_stop_port(), so it is indicator of whether the device needs to be restarted. Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
Exercised with "ip link set <PF intf> vf <vf_i> state {auto|enable|disable}" Sets the reporting policy for VF link state to either - mirror physical link state - always up - always down get VF link state mode in efx_ef10_sriov_get_vf_config Exercised by "ip link show <PF intf>"; output will include a line like vf 0 MAC 12:34:56:78:9a:bc, link-state auto Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
The max vlan tags that can be offloaded is 2, including any upstream VLAN aggregator. Currently there is no way for the net driver to know whether the upstream vswitch (if any) is using vlan tags, so there is no way to know how many tags we can request. Along with the implementation for the ndo_set_vf_vlan callback, this patch also adds 2 VLAN tags for the driver created VEB switch if possible, that way it is possible to offload as many tags as are allowed. Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jon Cooper authored
Currently we do an entity reset when we detect an MC reboot. This messes up SRIOV because it leaves VFs orphaned. The extra reset is rather redundant anyway, since the MC reboot will have basically reset everything. This change replaces the entity reset after MC reboot with a simpler datapath reset that reallocates resources but doesn't perform the entity reset. Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
rtnetlink calls ndo_get_vf_config when compiling information about a network interface, so that the VFs associated with a PF can be listed (eg: ip link show). Implement a response to this entry point and return PF-set MAC address for VF in ndo_get_vf_config Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
Implement a response to this entrypoint. The ndo_set_vf_mac() entrypoint is only exposed in the driver if CONFIG_SFC_SRIOV is defined. Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jon Cooper authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Pieczko authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shradha Shah authored
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: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vineet Gupta authored
This also matches with the sibling call netdev_alloc_skb_ip_align() made in rx fast path. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
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: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Simon Horman says: ==================== rocker: transaction fixes this series addresses what appear to be errors in the handling of prepare and then commit transactions in the rocker driver. In all cases the problem is that data structures visible outside of the transaction are modified during the prepare phase. In the case of the first two patches this results in the kernel reporting a BUG. I have noted test-cases in the change logs. The third patch is also a bug fix, as noted by Toshiaki Makita, however I have not been able to reliably reproduce the problem and thus have not provided a test case. The last patch is a correctness fix that does not fix a bug that manifests as far as I can tell. Changes: v3->v4 * All patches - Add Jiri Pirko's ack * "rocker: do not make neighbour entry changes when preparing transactions" - Setting of entry values in all transaction phases as suggested by Toshiaki Makita * "rocker: make rocker_port_internal_vlan_id_{get,put}() non-transactional" - Remove Fixes tag as I believe this is a correctness rather than a bug fix Changes: v2->v3 * "rocker: do not make neighbour entry changes when preparing transactions" - Correct inverted logic - Added ack from Scott Feldman Changes: v1->v2 * "rocker: do not make neighbour entry changes when preparing transactions" - Revised changelog to reflect information from Toshiaki Makita that there is a bug that can manifest - Update address and ttl regardless of the value of the transaction state * All other patches - Added acks from Scott Feldman ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
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: Scott Feldman <sfeldma@gmail.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
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: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by: Scott Feldman <sfeldma@gmail.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
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: Scott Feldman <sfeldma@gmail.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
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: Scott Feldman <sfeldma@gmail.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
Use the generic mechanism to declare a bitmap instead of unsigned long. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexei Starovoitov says: ==================== bpf: introduce bpf_tail_call() helper introduce bpf_tail_call(ctx, &jmp_table, index) helper function which can be used from BPF programs like: int bpf_prog(struct pt_regs *ctx) { ... bpf_tail_call(ctx, &jmp_table, index); ... } that is roughly equivalent to: int bpf_prog(struct pt_regs *ctx) { ... if (jmp_table[index]) return (*jmp_table[index])(ctx); ... } The important detail that it's not a normal call, but a tail call. The kernel stack is precious, so this helper reuses the current stack frame and jumps into another BPF program without adding extra call frame. It's trivially done in interpreter and a bit trickier in JITs. Use cases: - simplify complex programs - dispatch into other programs (for example: index in jump table can be syscall number or network protocol) - build dynamic chains of programs The chain of tail calls can form unpredictable dynamic loops therefore tail_call_cnt is used to limit the number of calls and currently is set to 32. patch 1 - support bpf_tail_call() in interpreter patch 2 - support in x64 JIT We've discussed what's neccessary to support it in arm64/s390 JITs and it looks fine. patch 3 - sample example for tracing patch 4 - sample example for networking More details in every patch. This set went through several iterations of reviews/fixes and older attempts can be seen: https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/log/?h=tail_call_v[123456] - tail_call_v1 does it without touching JITs but introduces overhead for all programs that don't use this helper function. - tail_call_v2 still has some overhead and x64 JIT does full stack unwind (prologue skipping optimization wasn't there) - tail_call_v3 reuses 'call' instruction encoding and has interpreter overhead for every normal call - tail_call_v4 fixes above architectural shortcomings and v5,v6 fix few more bugs This last tail_call_v6 approach seems to be the best. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-