- 24 Oct, 2015 6 commits
-
-
Jon Paul Maloy authored
The broadcast transmission link is currently instantiated when the network subsystem is started, i.e., on order from user space via netlink. This forces the broadcast transmission code to do unnecessary tests for the existence of the transmission link, as well in single mode node as in network mode. In this commit, we do instead create the link during initialization of the name space, and remove it when it is stopped. The fact that the transmission link now has a guaranteed longer life cycle than any of its potential clients paves the way for further code simplifcations and optimizations. Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jon Paul Maloy authored
The broadcast lock will need to be acquired outside bcast.c in a later commit. For this reason, we move the lock to struct tipc_net. Consistent with the changes in the previous commit, we also introducee two new functions tipc_bcast_lock() and tipc_bcast_unlock(). The code that is currently using tipc_bclink_lock()/unlock() will be phased out during the coming commits in this series. Signed-off-by:
-
Jon Paul Maloy authored
Currently, a number of structure and function definitions related to the broadcast functionality are unnecessarily exposed in the file bcast.h. This obscures the fact that the external interface towards the broadcast link in fact is very narrow, and causes unnecessary recompilations of other files when anything changes in those definitions. In this commit, we move as many of those definitions as is currently possible to the file bcast.c. We also rename the structure 'tipc_bclink' to 'tipc_bc_base', both since the name does not correctly describe the contents of this struct, and will do so even less in the future, and because we want to use the term 'link' more appropriately in the functionality introduced later in this series. Finally, we rename a couple of functions, such as tipc_bclink_xmit() and others that will be kept in the future, to include the term 'bcast' instead. There are no functional changes in this commit. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: net/ipv6/xfrm6_output.c net/openvswitch/flow_netlink.c net/openvswitch/vport-gre.c net/openvswitch/vport-vxlan.c net/openvswitch/vport.c net/openvswitch/vport.h The openvswitch conflicts were overlapping changes. One was the egress tunnel info fix in 'net' and the other was the vport ->send() op simplification in 'net-next'. The xfrm6_output.c conflicts was also a simplification overlapping a bug fix. Signed-off-by: -
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2015-10-22 Here's probably the last bluetooth-next pull request for 4.4. Among several other changes it contains the rest of the fixes & cleanups from the Bluetooth UnplugFest (that didn't need to be hurried to 4.3). - Refactoring & cleanups to 6lowpan code - New USB ids for two Atheros controllers and BCM43142A0 from Broadcom - Fix (quirk) for broken Broadcom BCM2045 controllers - Support for latest Apple controllers - Improvements to the vendor diagnostic message support Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
Michael Chan authored
struct bnxt_pf_info needs to be always defined. Move bnxt_update_vf_mac() to bnxt_sriov.c and add some missing #ifdef CONFIG_BNXT_SRIOV. Reported-by:
Jim Hull <jim.hull@hpe.com> Tested-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
- 23 Oct, 2015 34 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2015-10-23 This series contains updates to i40e, i40evf, if_link, ixgbe and ixgbevf. Anjali adds a workaround to drop any flow control frames from being transmitted from any VSI, so that a malicious VF cannot send flow control or PFC packets out on the wire. Also fixed a bug in debugfs by grabbing the filter list lock before adding or deleting a filter. Akeem fixes an issue where we were unconditionally returning VEB bridge mode before allowing LB in the add VSI routine, resolve by checking if the bridge is actually in VEB mode first. Mitch fixed an issue where the incorrect structure was being used for VLAN filter list, which meant the VLAN filter list did not get processed correctly and VLAN filters would not be re-enabled after any kind of reset. Helin fixed a problem of possibly getting inconsistent flow control status after a PF reset. The issue was requested_mode was being set with a default value during probe, but the hardware state could be a different value from this mode. Carolyn fixed a problem where the driver output of the OEM version string varied from the other tools. Jean Sacren fixes up kernel documentation by fixing function header comments to match actual variables used in the functions. Also cleaned up variable initialization, when the variable would be over-written immediately. Hiroshi Shimanoto provides three patches to add "trusted" VF by adding netlink directives and an NDO entry. Then implement these new controls in ixgbe and ixgbevf. This series has gone through several iterations to address all the suggested community changes and concerns. ==================== Signed-off-by: -
David S. Miller authored
Roopa Prabhu says: ==================== mpls: multipath support This patch adds support for MPLS multipath routes. Includes following changes to support multipath: - splits struct mpls_route into 'struct mpls_route + struct mpls_nh'. - struct mpls_nh represents a mpls nexthop label forwarding entry - Adds support to parse/fill RTA_MULTIPATH netlink attribute for multipath routes similar to ipv4/v6 fib - In the process of restructuring, this patch also consistently changes all labels to u8 $ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \ nexthop as 700 via inet 10.1.1.6 dev swp2 \ nexthop as 800 via inet 40.1.1.2 dev swp3 $ip -f mpls route show 100 nexthop as to 200 via inet 10.1.1.2 dev swp1 nexthop as to 700 via inet 10.1.1.6 dev swp2 nexthop as to 800 via inet 40.1.1.2 dev swp3 ==================== Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Robert Shearman authored
Change the selection of a multipath route to use a flow-based hash. This more suitable for traffic sensitive to reordering within a flow (e.g. TCP, L2VPN) and whilst still allowing a good distribution of traffic given enough flows. Selection of the path for a multipath route is done using a hash of: 1. Label stack up to MAX_MP_SELECT_LABELS labels or up to and including entropy label, whichever is first. 2. 3-tuple of (L3 src, L3 dst, proto) from IPv4/IPv6 header in MPLS payload, if present. Naturally, a 5-tuple hash using L4 information in addition would be possible and be better in some scenarios, but there is a tradeoff between looking deeper into the packet to achieve good distribution, and packet forwarding performance, and I have erred on the side of the latter as the default. Signed-off-by:
Robert Shearman <rshearma@brocade.com> Signed-off-by:
-
Roopa Prabhu authored
This patch adds support for MPLS multipath routes. Includes following changes to support multipath: - splits struct mpls_route into 'struct mpls_route + struct mpls_nh' - 'struct mpls_nh' represents a mpls nexthop label forwarding entry - moves mpls route and nexthop structures into internal.h - A mpls_route can point to multiple mpls_nh structs - the nexthops are maintained as a array (similar to ipv4 fib) - In the process of restructuring, this patch also consistently changes all labels to u8 - Adds support to parse/fill RTA_MULTIPATH netlink attribute for multipath routes similar to ipv4/v6 fib - In this patch, the multipath route nexthop selection algorithm simply returns the first nexthop. It is replaced by a hash based algorithm from Robert Shearman in the next patch - mpls_route_update cleanup: remove 'dev' handling in mpls_route_update. mpls_route_update though implemented to update based on dev, it was never used that way. And the dev handling gets tricky with multiple nexthops. Cannot match against any single nexthops dev. So, this patch removes the unused 'dev' handling in mpls_route_update. - dead route/path handling will be implemented in a subsequent patch Example: $ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \ nexthop as 700 via inet 10.1.1.6 dev swp2 \ nexthop as 800 via inet 40.1.1.2 dev swp3 $ip -f mpls route show 100 nexthop as to 200 via inet 10.1.1.2 dev swp1 nexthop as to 700 via inet 10.1.1.6 dev swp2 nexthop as to 800 via inet 40.1.1.2 dev swp3 Signed-off-by: -
Li RongQing authored
the returned buffer of register_sysctl() is stored into net_header variable, but net_header is not used after, and compiler maybe optimise the variable out, and lead kmemleak reported the below warning comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s) hex dump (first 32 bytes): 90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffc00020f134>] create_object+0x10c/0x2a0 [<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0 [<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8 [<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0 [<ffffffc00028eef0>] register_sysctl+0x30/0x40 [<ffffffc00099c304>] net_sysctl_init+0x20/0x58 [<ffffffc000994dd8>] sock_init+0x10/0xb0 [<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8 [<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0 [<ffffffc00070ed6c>] kernel_init+0x1c/0xe8 [<ffffffc000083bfc>] ret_from_fork+0xc/0x50 [<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>> Before fix, the objdump result on ARM64: 0000000000000000 <net_sysctl_init>: 0: a9be7bfd stp x29, x30, [sp,#-32]! 4: 90000001 adrp x1, 0 <net_sysctl_init> 8: 90000000 adrp x0, 0 <net_sysctl_init> c: 910003fd mov x29, sp 10: 91000021 add x1, x1, #0x0 14: 91000000 add x0, x0, #0x0 18: a90153f3 stp x19, x20, [sp,#16] 1c: 12800174 mov w20, #0xfffffff4 // #-12 20: 94000000 bl 0 <register_sysctl> 24: b4000120 cbz x0, 48 <net_sysctl_init+0x48> 28: 90000013 adrp x19, 0 <net_sysctl_init> 2c: 91000273 add x19, x19, #0x0 30: 9101a260 add x0, x19, #0x68 34: 94000000 bl 0 <register_pernet_subsys> 38: 2a0003f4 mov w20, w0 3c: 35000060 cbnz w0, 48 <net_sysctl_init+0x48> 40: aa1303e0 mov x0, x19 44: 94000000 bl 0 <register_sysctl_root> 48: 2a1403e0 mov w0, w20 4c: a94153f3 ldp x19, x20, [sp,#16] 50: a8c27bfd ldp x29, x30, [sp],#32 54: d65f03c0 ret After: 0000000000000000 <net_sysctl_init>: 0: a9bd7bfd stp x29, x30, [sp,#-48]! 4: 90000000 adrp x0, 0 <net_sysctl_init> 8: 910003fd mov x29, sp c: a90153f3 stp x19, x20, [sp,#16] 10: 90000013 adrp x19, 0 <net_sysctl_init> 14: 91000000 add x0, x0, #0x0 18: 91000273 add x19, x19, #0x0 1c: f90013f5 str x21, [sp,#32] 20: aa1303e1 mov x1, x19 24: 12800175 mov w21, #0xfffffff4 // #-12 28: 94000000 bl 0 <register_sysctl> 2c: f9002260 str x0, [x19,#64] 30: b40001a0 cbz x0, 64 <net_sysctl_init+0x64> 34: 90000014 adrp x20, 0 <net_sysctl_init> 38: 91000294 add x20, x20, #0x0 3c: 9101a280 add x0, x20, #0x68 40: 94000000 bl 0 <register_pernet_subsys> 44: 2a0003f5 mov w21, w0 48: 35000080 cbnz w0, 58 <net_sysctl_init+0x58> 4c: aa1403e0 mov x0, x20 50: 94000000 bl 0 <register_sysctl_root> 54: 14000004 b 64 <net_sysctl_init+0x64> 58: f9402260 ldr x0, [x19,#64] 5c: 94000000 bl 0 <unregister_sysctl_table> 60: f900227f str xzr, [x19,#64] 64: 2a1503e0 mov w0, w21 68: f94013f5 ldr x21, [sp,#32] 6c: a94153f3 ldp x19, x20, [sp,#16] 70: a8c37bfd ldp x29, x30, [sp],#48 74: d65f03c0 ret Add the possible error handle to free the net_header to remove the kmemleak warning Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Signed-off-by:
-
David S. Miller authored
Neil Armstrong says: ==================== Refactor nested mdiobus read/write functions In order to avoid locked signal false positive for nested mdiobus read/write calls, nested code was introduced in mv88e6xxx and mdio-mux. But mv88e6060 also needs such nested mdiobus read/write calls. For sake of refactoring, introduce nested variants of mdiobus read/write and make them used by mv88e6xxx and mv88e6060. In a next patch, mdio-mux should also use these variant calls. ==================== Signed-off-by: -
Neil Armstrong authored
Like mv88e6xxx and mdio-mux, to avoid lockdep give false positives because of nested MDIO busses, switch to previously introduced nested mdiobus_read/write variants. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Neil Armstrong authored
Make the mv88e6xxx driver use the previously introduced nested variants of mdiobus_read/write functions. Signed-off-by:
-
Neil Armstrong authored
Since nested variants of mdiobus_read/write are used in multiple drivers, add nested variants in the mdiobus core. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Hiroshi Shimamoto authored
The limitation of the number of multicast address for VF is not enough for the large scale server with SR-IOV feature. IPv6 requires the multicast MAC address for each IP address to handle the Neighbor Solicitation message. We couldn't assign over 30 IPv6 addresses to a single VF. This patch introduces the new mailbox API, IXGBE_VF_UPDATE_XCAST_MODE, to update multicast mode of VF. This adds 3 modes; - NONE only L2 exact match addresses or Flow Director enabled - MULTI BAM and ROMPE set - ALLMULTI BAM, ROMPE and MPE set If a guest VF user wants over 30 MAC multicast addresses, set IFF_ALLMULTI to request PF to update xcast mode to enable VF multicast promiscuous mode. On the other hand, enabling VF multicast promiscuous mode may affect security and performance in the network of the NIC. Only trusted VF can enable multicast promiscuous mode. The behavior of untrusted VF is the same as previous version. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Tested-by:
Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Hiroshi Shimamoto authored
Implements the new netdev op to trust VF in ixgbe. The administrator can turn on and off VF trusted by ip command which supports trust message. # ip link set dev eth0 vf 1 trust on or # ip link set dev eth0 vf 1 trust off Send a ping to reset VF on changing the status of trusting. VF driver will reconfigure its features on reset. Signed-off-by:
-
Grygorii Strashko authored
There is no reasons to probe cpsw from late_initcall level and it's not recommended. Hence, use module_platform_driver() to register and probe cpsw driver from module_init() level. Cc: Tony Lindgren <tony@atomide.com> Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Hiroshi Shimamoto authored
Add netlink directives and ndo entry to trust VF user. This controls the special permission of VF user. The administrator will dedicatedly trust VF user to use some features which impacts security and/or performance. The administrator never turn it on unless VF user is fully trusted. CC: Sy Jong Choi <sy.jong.choi@intel.com> Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Tested-by:
-
Eric Dumazet authored
Multiple cpus can process duplicates of incoming ACK messages matching a SYN_RECV request socket. This is a rare event under normal operations, but definitely can happen. Only one must win the race, otherwise corruption would occur. To fix this without adding new atomic ops, we use logic in inet_ehash_nolisten() to detect the request was present in the same ehash bucket where we try to insert the new child. If request socket was not found, we have to undo the child creation. This actually removes a spin_lock()/spin_unlock() pair in reqsk_queue_unlink() for the fast path. Fixes: e994b2f0 ("tcp: do not lock listener to process SYN packets") Fixes: 079096f1 ("tcp/dccp: install syn_recv requests into ehash table") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jean Sacren authored
The commit 3092e5e4cc79 ("i40e: add little endian conversion for checksum") fixed the checksum bug on big-endian architecture. But we should not execute cpu_to_le16() unconditionally. Thus, put cpu_to_le16() under certain condition. Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Signed-off-by:Jean Sacren <sakiwit@gmail.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Jean Sacren authored
In both i40e_calc_nvm_checksum() and i40e_update_nvm_checksum(), the local variables designated by 'ret_code' are overwritten immediately. As such, they should merely be declared. Signed-off-by:
-
Jean Sacren authored
In i40evf_msix_aq(), the first two lines of rd32() are mainly to clear the registers. If we initialize 'val' at this point, it will be overwritten immediately. We shall simply discard the return value here. When we initialize 'val', we might as well include the mask in one step. Signed-off-by:
-
Jean Sacren authored
The following kernel-doc arguments for their respective functions are missing: 1) @cd_type_cmd_tso_mss for i40e_tso(); 2) @cd_type_cmd_tso_mss for i40e_tsyn(); 3) @tx_ring for i40e_tx_enable_csum(). Add them all for the kernel-doc requirement. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Jean Sacren authored
@flush has been missing since the inception of i40evf_irq_enable(). Add it for the kernel doc. Signed-off-by:
-
Andy Shevchenko authored
Instead of using a custom approach change the code to use %*ph format specifier. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
-
Catherine Sullivan authored
Bump up the version... Change-ID: Ib8d501021671ba20250115ed54330e2c182255b7 Signed-off-by:
Catherine Sullivan <catherine.sullivan@intel.com> Tested-by:
-
Akeem G Abodunrin authored
If a call to enable SR-IOV in the kernel failed, we need to disable I40E_FLAG_VEB_MODE_ENABLED, so that bridge mode could fall back to VEPA, which is a default. Change-ID: I12b6f776769506db85b29bea94b9c88d0b5ee65e Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by:
-
Carolyn Wyborny authored
This patch fixes a problem where the driver output of the OEM version string varied from the other tools. The mask value and the order of operations were incorrect, per the original change request. Without this patch, the version string will appear incorrect from the driver. Change-ID: Ie1ca6485284b4ce3b57e5a99b18b7641617c7ef7 Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
-
Helin Zhang authored
This patch fixes a problem of possibly getting inconsistent flow control statuses after a PF reset. Requested_mode was being set with a default value during probing, but the initial HW state could be different from this mode. Change-ID: I772bf07b78616e87086418d4bd87954b66fa17cd Signed-off-by:
Helin Zhang <helin.zhang@intel.com> Tested-by:
-
Mitch Williams authored
Not sure how this compiles at all. Use the correct struct for manipulating the VLAN filter list. Without this, the VLAN filter list doesn't get processed correctly, and VLAN filters will not be re-enabled after any kind of reset. Change-ID: Iceff2dc089f303058fb71ecb08419eed471e0e90 Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Akeem G Abodunrin authored
Fix i40e_is_vsi_uplink_mode_veb to check if bridge is actually in VEB mode before allowing LB in the add VSI routine, instead of unconditionally returning VEB bridge mode. Change-ID: I162397b1bdd02367735fe9baaeb51465be2a3ce9 Signed-off-by:
-
Anjali Singhai Jain authored
The new code flow requires us to grab the filter list lock before adding/deleting the filter. Change-ID: I4eaef508ab4da2d1b2e23f20f2a78d931d5b6aeb Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
-
Anjali Singhai Jain authored
This patch adds a workaround to drop any flow control frames from being transmitted from any VSI. FW can still send flow control frames if flow control is enabled. With this patch in place a malicious VF cannot send flow control or PFC packets out on the wire. Change-ID: I4303b24e98b93066d2767fec24dfe78be591c277 Signed-off-by:
-
Guillaume Nault authored
We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL). Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state. Fixes: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Li RongQing authored
Signed-off-by:
-
Lendacky, Thomas authored
The code currently uses the lightweight dma_wmb barrier before updating the current descriptor count. Under heavy load, the Tx cleanup routine was seeing the updated current descriptor count before the updated descriptor information. As a result, the Tx descriptor was being cleaned up before it was used because it was not "owned" by the hardware yet, resulting in a Tx queue hang. Using the wmb barrier insures that the descriptor is updated before the descriptor counter preventing the Tx queue hang. For extra insurance, the Tx cleanup routine is changed to grab the current decriptor count on entry and uses that initial value in the processing loop rather than trying to chase the current value. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Tested-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Nathan Sullivan authored
Very rarely, the KSZ9031 will appear to complete autonegotiation, but will drop all traffic afterwards. When this happens, the idle error count will read 0xFF after autonegotiation completes. Reset the PHY when in that state. Signed-off-by:
Nathan Sullivan <nathan.sullivan@ni.com> Signed-off-by:
-
Paolo Abeni authored
Currently adding a new ipv4 address always cause the creation of the related network route, with default metric. When a host has multiple interfaces on the same network, multiple routes with the same metric are created. If the userspace wants to set specific metric on each routes, i.e. giving better metric to ethernet links in respect to Wi-Fi ones, the network routes must be deleted and recreated, which is error-prone. This patch implements the support for IFA_F_NOPREFIXROUTE for ipv4 address. When an address is added with such flag set, no associated network route is created, no network route is deleted when said IP is gone and it's up to the user space manage such route. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
David S. Miller authored
Hannes Frederic Sowa says: ==================== overflow-arith: begin to add support for overflow builtins functions I add a new header, linux/overflow-arith.h, as the central place to add overflow and wrap-around checking functions. The reason I am doing so is that it can make use of compiler supported builtin functions which can leverage hardware. As I need this for a fix in the ipv6 stack, which is also included in this series, I propose to add it sooner than later over Davem's net tree. This is also the reason why I start slowly with only the one function I need at this time. ==================== Signed-off-by:
-
