- 14 Jun, 2017 5 commits
-
-
Yonghong Song authored
Currently, verifier will reject a program if it contains an narrower load from the bpf context structure. For example, __u8 h = __sk_buff->hash, or __u16 p = __sk_buff->protocol __u32 sample_period = bpf_perf_event_data->sample_period which are narrower loads of 4-byte or 8-byte field. This patch solves the issue by: . Introduce a new parameter ctx_field_size to carry the field size of narrower load from prog type specific *__is_valid_access validator back to verifier. . The non-zero ctx_field_size for a memory access indicates (1). underlying prog type specific convert_ctx_accesses supporting non-whole-field access (2). the current insn is a narrower or whole field access. . In verifier, for such loads where load memory size is less than ctx_field_size, verifier transforms it to a full field load followed by proper masking. . Currently, __sk_buff and bpf_perf_event_data->sample_period are supporting narrowing loads. . Narrower stores are still not allowed as typical ctx stores are just normal stores. Because of this change, some tests in verifier will fail and these tests are removed. As a bonus, rename some out of bound __sk_buff->cb access to proper field name and remove two redundant "skb cb oob" tests. Acked-by:Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Zhang Shengju authored
The macvlan dev should propagate the return value of mac address change for lower device in the passthru mode, instead of always return 0. Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2017-06-13 This series contains updates to ixgbe and ixgbevf only. Jake completes his fix ups for our drivers with the ixgbe changes to resolve a race condition in processing timestamp requests. These fixes are the same fixes Jake applied earlier to the other drivers, including the added statistic to help administrators know when an application timestamp request is ignored. With all the recent ixgbe/ixgbevf changes and fixes, Tony bumps the the driver versions. Then Tony provides a fix to resolve a static analysis warning by changing a variable to unsigned integer since the value can never be negative. Emil fixes an issue for X550 devices where the qde parameter was being ignored, so PFQDE.HIDE_VLAN was not being set. Jeff Mahoney from SuSE fixes a possible kernel crash, where there was a small window where tasks writing to the sriov_numvfs sysfs attribute can sneak in after we call register_netdev(). So we need to call pci_set_drvdata() before and not after register_netdev() to preserve the intent of commit 0fb6a55c ("ixgbe: fix crash on rmmod after probe fail"). ==================== Signed-off-by:
-
Jeff Mahoney authored
We call pci_set_drvdata immediately after calling register_netdev, which leaves a window where tasks writing to the sriov_numvfs sysfs attribute can sneak in and crash the kernel. register_netdev cleans up after itself so placing pci_set_drvdata immediately before it should preserve the intent of commit 0fb6a55c ("ixgbe: fix crash on rmmod after probe fail"). Fixes: 0fb6a55c ("ixgbe: fix crash on rmmod after probe fail") Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Tony Nguyen authored
cppcheck warns that the format string is incorrect in the function ixgbe_get_strings(). Since the value cannot be negative, change the variable to unsigned which matches the format specifier. Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by:
-
- 13 Jun, 2017 35 commits
-
-
Emil Tantilov authored
ixgbe_write_qde() was ignoring the qde parameter which resulted in PFQDE.HIDE_VLAN not being set for X550. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
-
Tony Nguyen authored
Update ixgbevf version number. Signed-off-by:
-
Tony Nguyen authored
Update ixgbe version number. Signed-off-by:
-
Jacob Keller authored
The ixgbe driver has logic to handle only one Tx timestamp at a time, using a state bit lock to avoid multiple requests at once. It may be possible, if incredibly unlikely, that a Tx timestamp event is requested but never completes. Since we use an interrupt scheme to determine when the Tx timestamp occurred we would never clear the state bit in this case. Add an ixgbe_ptp_tx_hang() function similar to the already existing ixgbe_ptp_rx_hang() function. This function runs in the watchdog routine and makes sure we eventually recover from this case instead of permanently disabling Tx timestamps. Note: there is no currently known way to cause this without hacking the driver code to force it. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
-
Jacob Keller authored
The ixgbe driver can only handle one Tx timestamp request at a time. This means it is possible for an application timestamp request to be ignored. There is no easy way for an administrator to determine if this occurred. Add a new statistic which tracks this, tx_hwtstamp_skipped. Signed-off-by:
-
Jacob Keller authored
The ixgbe driver uses a state bit lock to avoid handling more than one Tx timestamp request at once. This is required because hardware is limited to a single set of registers for Tx timestamps. The state bit lock is not properly cleaned up during ixgbe_xmit_frame_ring() if the transmit fails such as due to DMA or TSO failure. In some hardware this results in blocking timestamps until the service task times out. In other hardware this results in a permanent lock of the timestamp bit because we never receive an interrupt indicating the timestamp occurred, since indeed the packet was never transmitted. Fix this by checking for DMA and TSO errors in ixgbe_xmit_frame_ring() and properly cleaning up after ourselves when these occur. Reported-by:
Reported-by: David Mirabito <davidm@metamako.com> Signed-off-by:
-
Jacob Keller authored
Hardware related to the ixgbe driver is limited to handling a single Tx timestamp request at a time. Thus, the driver ignores requests for Tx timestamp while waiting for the current request to finish. It uses a state bit lock which enforces that only one timestamp request is honored at a time. Unfortunately this suffers from a simple race condition. The bit lock is not cleared until after skb_tstamp_tx() is called notifying applications of a new Tx timestamp. Even a well behaved application sending only one packet at a time and waiting for a response can wake up and send a new packet before the bit lock is cleared. This results in needlessly dropping some Tx timestamp requests. We can fix this by unlocking the state bit as soon as we read the Timestamp register, as this is the first point at which it is safe to unlock. To avoid issues with the skb pointer, we'll use a copy of the pointer and set the global variable in the driver structure to NULL first. This ensures that the next timestamp request does not modify our local copy of the skb pointer. This ensures that well behaved applications do not accidentally race with the unlock bit. Obviously an application which sends multiple Tx timestamp requests at once will still only timestamp one packet at a time. Unfortunately there is nothing we can do about this. Reported-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: Multi-CPU ground work (v4) This patch series prepares the ground for adding mutliple CPU port support to DSA, and starts by removing redundant pieces of information such as master_netdev which is cpu_dp->ethernet. Finally drivers are moved away from directly accessing ds->dst->cpu_dp and use appropriate helper functions. Note that if you have Device Tree blobs/platform configurations that are currently listing multiple CPU ports, the proposed behavior in dsa_ds_get_cpu_dp() will be to return the last bit set in ds->cpu_port_mask. Future plans include: - making dst->cpu_dp a flexible data structure (array, list, you name it) - having the ability for drivers to return a default/preferred CPU port (if necessary) Changes in v4: - fixed build warning with NETPOLL enabled Changes in v3: - removed the last patch since it causes problems with bcm_sf2/b53 in a dual-CPU case (root cause known, proper fix underway) - removed dsa_ds_get_cpu_dp() Changes in v2: - added Reviewed-by tags - assign port->cpu_dp earlier before ops->setup() has run ==================== Signed-off-by: -
Florian Fainelli authored
Introduce a helper function which will return a reference to the CPU port used in a dsa_switch_tree. Right now this is a singleton, but this will change once we introduce multi-CPU port support, so ease the transition by converting the affected code paths. Reviewed-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
In preparation for supporting multiple CPU ports with DSA, have the dsa_port structure know which CPU it is associated with. This will be important in order to make sure the correct CPU is used for transmission of the frames. If not for functional reasons, for performance (e.g: load balancing) and forwarding decisions. Reviewed-by:
-
Florian Fainelli authored
Relocate master_ethtool_ops and master_orig_ethtool_ops into struct dsa_port in order to be both consistent, and make things self contained within the dsa_port structure. This is a preliminary change to supporting multiple CPU port interfaces. Reviewed-by:
-
Florian Fainelli authored
In preparation for supporting multiple CPU ports, remove dst->master_netdev and ds->master_netdev and replace them with only one instance of the common object we have for a port: struct dsa_port::netdev. ds->master_netdev is currently write only and would be helpful in the case where we have two switches, both with CPU ports, and also connected within each other, which the multi-CPU port patch series would address. While at it, introduce a helper function used in net/dsa/slave.c to immediately get a reference on the master network device called dsa_master_netdev(). Reviewed-by:
-
Ganesh Goudar authored
If SF bit is not cleared in PL_INT_CAUSE, subsequent non-data interrupts are not raised. Enable SF bit in Global Interrupt Mask and handle it as non-fatal and hence eventually clear it. Signed-off-by:
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Jon Mason authored
The of_mdio_parse_addr() helper function is useful to other code, but the module dependency chain causes issues. To work around this, we can move of_mdio_parse_addr() to be an inline function in the header file. This gets rid of the dependencies and still allows for the reuse of code. Reported-by:
Liviu Dudau <liviu@dudau.co.uk> Signed-off-by:
Jon Mason <jon.mason@broadcom.com> Fixes: 342fa196 ("mdio: mux: make child bus walking more permissive and errors more verbose") Reviewed-by:
-
Jesper Dangaard Brouer authored
The selftests depend on using the shell exit code as a mean of detecting the success or failure of test-binary executed. The appropiate output "[PASS]" or "[FAIL]" in generated by tools/testing/selftests/lib.mk. Notice that the exit code is masked with 255. Thus, be careful if using the number of errors as the exit code, as 256 errors would be seen as a success. There are two standard defined exit(3) codes: /usr/include/stdlib.h #define EXIT_FAILURE 1 /* Failing exit status. */ #define EXIT_SUCCESS 0 /* Successful exit status. */ Fix test_verifier.c to not use the negative value of variable "results", but instead return EXIT_FAILURE. Fix test_align.c and test_progs.c to actually use exit codes, before they were always indicating success regardless of results. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Zhang Shengju authored
Remove unnecessary setting of flag IFF_BROADCAST, since ether_setup already does this. Signed-off-by:
-
Johannes Berg authored
Use the recently introduced helper to replace the pattern of skb_put() && memset(), this transformation was done with the following spatch: @@ identifier p; expression len; expression skb; @@ -p = skb_put(skb, len); -memset(p, 0, len); +p = skb_put_zero(skb, len); Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2017-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== A couple of weeks worth of updates - looks like things are quiet: * merged net-next back to get a patch from net that another patch here depends on * various small improvements/cleanups across the board * 4-way handshake offload (many thanks to Arend for shepherding that) * mesh CSA/DFS support in mac80211 * the skb_put_zero() we discussed previously ==================== Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This feature/cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - decrease maximum fragment size, by Matthias Schiffer - Clean up seqfile writing, by Markus Elfring (2 patches) - use __func__ in debug messages, by Sven Eckelmann - Mark tpmeter initializers with __init, by Antonio Quartulli - ignore loop detection MAC addresses, by Simon Wunderlich - clean up some return handling, by Simon Wunderlich - improve ELP throughput value handling for WiFi neighbors in BATMAN V/ELP, by Sven Eckelmann (2 patches) ==================== Signed-off-by: -
yuval.shaia@oracle.com authored
Make return value void since function never return meaningfull value Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Acked-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
David S. Miller authored
Sergei Shtylyov says: ==================== MDIO bus reset GPIO cleanups Commit 4c5e7a2c ("dt-bindings: mdio: Clarify binding document") declared that a MDIO reset GPIO property should have only a single GPIO reference/specifier, however the supporting code was left intact... Here's a couple of the obvious cleanups to that code: [1/2] mdio_bus: handle only single PHY reset GPIO [2/2] mdio_bus: use devm_gpiod_get_optional() ==================== Signed-off-by:
-
Sergei Shtylyov authored
The MDIO reset GPIO is really a classical optional GPIO property case, so devm_gpiod_get_optional() should have been used, not devm_gpiod_get(). Doing this saves several LoCs... Signed-off-by:
-
Sergei Shtylyov authored
Commit 4c5e7a2c ("dt-bindings: mdio: Clarify binding document") declared that a MDIO reset GPIO property should have only a single GPIO reference/specifier, however the supporting code was left intact, still burdening the kernel with now apparently useless loops -- get rid of them. Signed-off-by:
-
Nathan Fontenot authored
When handling a driver reset due to a failover of the backing server on the vios, doing the netdev_notify_peers() can cause network traffic to stall or halt. Remove the netdev notify call for failover resets. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Thomas Falcon authored
The IBM vNIC protocol provides support for the user to initiate a failover from the client LPAR in case the current backing infrastructure is deemed inadequate or in an error state. Support for two H_VIOCTL sub-commands for vNIC devices are required to implement this function. These commands are H_GET_SESSION_TOKEN and H_SESSION_ERR_DETECTED. "[H_GET_SESSION_TOKEN] is used to obtain a session token from a VNIC client adapter. This token is opaque to the caller and is intended to be used in tandem with the SESSION_ERROR_DETECTED vioctl subfunction." "[H_SESSION_ERR_DETECTED] is used to report that the currently active backing device for a VNIC client adapter is behaving poorly, and that the hypervisor should attempt to fail over to a different backing device, if one is available." To provide tools access to this functionality the vNIC driver creates a sysfs file that, when written to, will send a request to pHyp to failover to a different backing device. Signed-off-by:
Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Reviewed-by:
-
Antoine Ténart authored
On GOP port 0 two MAC modes are available: GMAC and XLG. The XLG MAC is used for 10G connectivity. This patch adds a basic 10G support by allowing to use the XLG MAC on port 0 and by reworking the port_enable/disable functions so that the XLG MAC is configured when using 10G. Signed-off-by:
Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: mv88e6xxx: port macros cosmetics This patch series brings no functional changes. It prefixes all common port registers macros with MV88E6XXX_PORT. If registers or some bits differs between switch models, a reference model is chosen (e.g. MV88E6390_PORT_MAC_CTL_SPEED_10000.) The register names are documented as found in the datasheets. Avoid BIT() and shifts defines and prefer a better representation of the Marvell switch registers with ordered, hexadecimal, 16-bit values. ==================== Signed-off-by: -
Vivien Didelot authored
For implicit namespacing and clarity, prefix the remaining common Port Registers macros with MV88E6XXX_PORT. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port IEEE Priority Remapping registers macros with MV88E6095_PORT_IEEE_PRIO. The 88E6390 family turned the 0x18 register into a single indirect table, document that at the same time. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Also fix the following checkpatch checks with a temporary variable: CHECK: Alignment should match open parenthesis #65: FILE: drivers/net/dsa/mv88e6xxx/port.c:932: + err = mv88e6xxx_port_ieeepmt_write(chip, port, + MV88E6390_PORT_IEEE_PRIO_MAP_TABLE_INGRESS_PCP, Signed-off-by: -
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Association Vector Register macros with MV88E6XXX_PORT_ASSOC_VECTOR. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Egress Rate Control and Port Egress Rate Control 2 registers macros with MV88E6XXX_PORT_EGRESS_RATE_CTL1 and MV88E6XXX_PORT_EGRESS_RATE_CTL2. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Control 2 Register macros with MV88E6XXX_PORT_CTL2 and the ones which differ between implementations with a chosen reference model (e.g. MV88E6095_PORT_CTL2_CPU_PORT_MASK.) Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Default VLAN Register macros with MV88E6XXX_PORT_DEFAULT_VLAN. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Based VLAN Register macros with MV88E6XXX_PORT_BASE_VLAN. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
Vivien Didelot authored
For implicit namespacing and clarity, prefix the common Port Control 1 Register macros with MV88E6XXX_PORT_CTL1. Document the register and prefer ordered hex masks values for all Marvell 16-bit registers. Signed-off-by:
-
