- 02 Sep, 2015 1 commit
-
-
David S. Miller authored
These cannot live in net/core/flow.c which only builds when XFRM is enabled. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 01 Sep, 2015 18 commits
-
-
David S. Miller authored
Just have a flags member instead. In file included from include/linux/linkage.h:4:0, from include/linux/kernel.h:6, from net/core/flow_dissector.c:1: In function 'flow_keys_hash_start', inlined from 'flow_hash_from_keys' at net/core/flow_dissector.c:553:34: >> include/linux/compiler.h:447:38: error: call to '__compiletime_assert_459' declared with attribute error: BUILD_BUG_ON failed: FLOW_KEYS_HASH_OFFSET % sizeof(u32) Reported-by: -
David S. Miller authored
Tom Herbert says: ==================== flow_dissector: Paramterize dissection and other features This patch set adds some new capabilities to flow_dissector: - Add flags to flow dissector functions to control dissection - Flag to stop dissection when L3 header is seen (don't dissect L4) - Flag to stop dissection when encapsulation is detected - Flag to parse first fragment of fragmented packet. This may provide L4 ports - Added new reporting in key_control - Packet is a fragment - Packet is a first fragment - Packet has encapsulation Also: - Make __skb_set_sw_hash a general function - Create functions to get a flow hash based on flowi4 or flowi6 structures without an reference to an skbuff - Ignore flow dissector return value from ___skb_get_hash. Just use whatever key fields are found to make a hash Tested: Ran 200 netperf TCP_RR instances for IPv6 and IPv4. Did not see any regression. Ran UDP_RR with 10000 byte request and response size for IPv4 and IPv6, no regression observed however I did see better performance with IPv6 flow labels due to use of flow labels for L4 hash. ==================== Signed-off-by: -
Tom Herbert authored
In ___skb_get_hash ignore return value from skb_flow_dissect_flow_keys. A failure in that function likely means that there was a parse error, so we may as well use whatever fields were found before the error was hit. This is also good because it means we won't keep trying to derive the hash on subsequent calls to skb_get_hash for the same packet. Signed-off-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Tom Herbert authored
Add an input flag to flow dissector on rather dissection should stop when encapsulation is detected (IP/IP or GRE). Also, add a key_control flag that indicates encapsulation was encountered during the dissection. Signed-off-by:
-
Tom Herbert authored
Add an input flag to flow dissector on rather dissection should be stopped when a flow label is encountered. Presumably, the flow label is derived from a sufficient hash of an inner transport packet so further dissection is not needed (that is ports are not included in the flow hash). Using the flow label instead of ports has the additional benefit that packet fragments should hash to same value as non-fragments for a flow (assuming that the same flow label is used). We set this flag by default in for skb_get_hash. Signed-off-by:
-
Tom Herbert authored
Add an input flag to flow dissector on rather dissection should be stopped when an L3 packet is encountered. This would be useful if a caller just wanted to get IP addresses of the outermost header (e.g. to do an L3 hash). Signed-off-by:
-
Tom Herbert authored
Parse NEXTHDR_FRAGMENT. When seen account for it in the fragment bits of key_control. Also, check if first fragment should be parsed. Signed-off-by:
-
Tom Herbert authored
Add an input flag to flow dissector on rather dissection should be attempted on a first fragment. Also add key_control flags to indicate that a packet is a fragment or first fragment. Signed-off-by:
-
Tom Herbert authored
The flags argument will allow control of the dissection process (for instance whether to parse beyond L3). Signed-off-by:
-
Tom Herbert authored
Instead of returning immediately (on a parsing failure for instance) we jump to cleanup code. This always sets protocol values in key_control (even on a failure there is still valid information in the key_tags that was set before the problem was hit). Signed-off-by:
-
Tom Herbert authored
Create __get_hash_from_flowi6 and __get_hash_from_flowi4 to get the flow keys and hash based on flowi structures. These are called by __skb_get_hash_flowi6 and __skb_get_hash_flowi4. Also, created get_hash_from_flowi6 and get_hash_from_flowi4 which can be called when just the hash value for a flowi is needed. Signed-off-by:
-
Tom Herbert authored
Move __skb_set_sw_hash to skbuff.h and add __skb_set_hash which is a common method (between __skb_set_sw_hash and skb_set_hash) to set the hash in an skbuff. Also, move skb_clear_hash to be closer to __skb_set_hash. Signed-off-by:
-
Tom Herbert authored
Move the flow dissector functions that are specific to skbuffs into skbuff.h out of flow_dissector.h. This makes flow_dissector.h have no dependencies on skbuff.h. Signed-off-by:
-
Jean Delvare authored
The temperature registers appear to report values in degrees Celsius while the hwmon API mandates values to be exposed in millidegrees Celsius. Do the conversion so that the values reported by "sensors" are correct. Fixes: aed93e0b ("tg3: Add hwmon support for temperature") Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Prashant Sreedharan <prashant@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: stable@vger.kernel.org [v3.6+] Signed-off-by:
-
Mark Salter authored
commit 8b63ec18 ("phylib: Make PHYs children of their MDIO bus, not the bus' parent.") uncovered a problem in mdiobus_unregister() which leads to this warning when I reboot an APM Mustang (arm64) platform: WARNING: CPU: 7 PID: 4239 at fs/sysfs/group.c:224 sysfs_remove_group+0xa0/0xa4() sysfs group fffffe0000e07a10 not found for kobject 'xgene-mii-eth0:03' ... CPU: 7 PID: 4239 Comm: reboot Tainted: G E 4.2.0-0.18.el7.test15.aarch64 #1 Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Aug 26 2015 Call Trace: [<fffffe000009739c>] dump_backtrace+0x0/0x170 [<fffffe000009752c>] show_stack+0x20/0x2c [<fffffe00007436f0>] dump_stack+0x78/0x9c [<fffffe00000c2cb4>] warn_slowpath_common+0xa0/0xd8 [<fffffe00000c2d60>] warn_slowpath_fmt+0x74/0x88 [<fffffe0000293d3c>] sysfs_remove_group+0x9c/0xa4 [<fffffe00004a8bac>] dpm_sysfs_remove+0x5c/0x70 [<fffffe000049b388>] device_del+0x44/0x208 [<fffffe000049b578>] device_unregister+0x2c/0x7c [<fffffe000050dc68>] mdiobus_unregister+0x48/0x94 [<fffffe000052afd0>] xgene_enet_mdio_remove+0x28/0x44 [<fffffe000052d3f0>] xgene_enet_remove+0xd0/0xd8 [<fffffe000052d424>] xgene_enet_shutdown+0x2c/0x3c [<fffffe00004a204c>] platform_drv_shutdown+0x24/0x40 [<fffffe000049d4f4>] device_shutdown+0xf0/0x1b4 [<fffffe00000e31ec>] kernel_restart_prepare+0x40/0x4c [<fffffe00000e32f8>] kernel_restart+0x1c/0x80 [<fffffe00000e3670>] SyS_reboot+0x17c/0x250 The problem is that mdiobus_unregister() deletes the bus device before unregistering the phy devices on the bus. This wasn't a problem before because the phys were not children of the bus: /sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0:03 /sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0 But now that they are: /sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0/xgene-mii-eth0:03 when mdiobus_unregister deletes the bus device, the phy subdirs are removed from sysfs also. So when the phys are unregistered afterward, we get the warning. This patch changes the order so that phys are unregistered before the bus device is deleted. Fixes: 8b63ec18 ("phylib: Make PHYs children of their MDIO bus, not the bus' parent.") Signed-off-by:
Mark Salter <msalter@redhat.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Mark Langsdorf <mlangsdo@redhat.com> Signed-off-by:
-
David Ahern authored
A number of VRF patches used 'int' for table id. It should be u32 to be consistent with the rest of the stack. Fixes: 4e3c8992 ("net: Introduce VRF related flags and helpers") 15be405e ("net: Add inet_addr lookup by table") 30bbaa19 ("net: Fix up inet_addr_type checks") 021dd3b8 ("net: Add routes to the table associated with the device") dc028da5 ("inet: Move VRF table lookup to inlined function") f6d3c192 ("net: FIB tracepoints") Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Pravin B Shelar authored
opts_size is only written and never read. Following patch removes this unused variable. Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Marius Tomaschewski authored
Signed-off-by:
Marius Tomaschewski <mt@suse.de> Signed-off-by:
-
- 31 Aug, 2015 21 commits
-
-
Eric Dumazet authored
As David pointed out, spinlock are no longer needed to protect the per cpu queues used in gro cells infrastructure. Also use new napi_complete_done() API so that gro_flush_timeout tweaks have an effect. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David Ward authored
Other Sierra Wireless MC73xx devices exist, with different USB IDs. Cc: Bjørn Mork <bjorn@mork.no> Signed-off-by:
David Ward <david.ward@ll.mit.edu> Signed-off-by:
-
Marius Tomaschewski authored
The kernel is applying the RA managed/otherconf flags silently and forgets to send ifinfo notify to inform about their change when the router provides a zero reachable_time and retrans_timer as dnsmasq and many routers send it, which just means unspecified by this router and the host should continue using whatever value it is already using. Userspace may monitor the ifinfo notifications to activate dhcpv6. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== DSA port configuration and status This patchset allows various switch port settings to be configured and port status to be sampled. Some of these patches have been posted before. The first three patches provide infrastructure for configuring a switch ports link speed and duplex from a fixed_link phy. Patch four then uses this infrastructure to allow the CPU and DSA ports of a switch to be configured using a fixed-link property in the device tree. Patches five and six allow a phy-mode property to be specified in the device tree, and allow this to be used for configuring RGMII delays. Patches seven through nine allow link status, for example that of an SFP module, to be read from a gpio. Changes since v1: Rewrite 9/9 so that it hopefully does not regression on 868a4215 ("net: phy: fixed_phy: handle link-down case") ==================== Signed-off-by:
-
Andrew Lunn authored
What features a phy supports is masked in genphy_config_init() by looking at the PHYs BMSR register. If the link is down, fixed_phy_update_regs() will only set the auto- negotiation capable bit in BMSR. Thus genphy_config_init() comes to the conclusion the PHY can only perform 10/Half, and masks out the higher speed features. If however the link it up, BMSR is set to indicate the speed the PHY is capable of auto-negotiating, and genphy_config_init() does not mask out the high speed features. To fix this, when the link is down, have fixed_phy_update_regs() leave the link status, auto-negotiation complete, and link partner capabilities unset, but set all the local capabilities depending on the fixed phy speed. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
An SFP module may have a link up/down status pin which can be connection to a GPIO line of the host. Add support for reading such an GPIO in the fixed_phy driver. Signed-off-by:
-
Andrew Lunn authored
When polling for link status, don't consider ports which have a forced link. Such ports don't monitor their phy or may not even have a phy. Signed-off-by:
-
Andrew Lunn authored
Some Marvell switches allow the RGMII Rx and Tx clock to be delayed when the port is using RGMII. Have the adjust_link function look at the phy interface type and enable this delay as requested. Signed-off-by:
-
Andrew Lunn authored
It can be useful for DSA and CPU ports to have a phy-mode property, in particular to specify RGMII delays. Parse the property and set it in the fixed-link phydev. Signed-off-by:
-
Andrew Lunn authored
By default, DSA and CPU ports are configured to the maximum speed the switch supports. However there can be use cases where the peer devices port is slower. Allow a fixed-link property to be used with the DSA and CPU port in the device tree, and use this information to configure the port. Signed-off-by:
-
Andrew Lunn authored
Set the supported field of the phydev to indicate the speed features of the phy. If the phy is never attached to a netdev, but used in an adjust_link() function, the speed will be incorrectly evaluated to 10/half rather than the correct speed/duplex. Signed-off-by:
-
Andrew Lunn authored
The current code sets user ports to perform auto negotiation using the phy. CPU and DSA ports are configured to full duplex and maximum speed the switch supports. There are however use cases where the CPU has a slower port, and when user ports have SFP modules with fixed speed. In these cases, port settings to be read from a fixed_phy devices. The switch driver then needs to implement the adjust_link op, so the port settings can be set. Signed-off-by:
-
Florian Fainelli authored
Some Ethernet MAC drivers using the PHY library require the hardcoding of link parameters when interfaced to a switch device, SFP module, switch to switch port, etc. This has typically lead to various ad-hoc implementations looking like this: - using a "fixed PHY" emulated device, which will provide link indication towards the Ethernet MAC driver and hardware - pretend there is no PHY and hardcode link parameters, ala mv643x_eth Based on that, it is desireable to have the PHY drivers advertise the correct link parameters, just like regular Ethernet PHYs towards their CPU Ethernet MAC drivers, however, Ethernet MAC drivers should be able to tell whether this link should be monitored or not. In the context of an Ethernet switch, SFP module, switch to switch link, we do not need to monitor this link since it should be always up. Signed-off-by:
-
Nikolay Aleksandrov authored
Fix a memory leak in the mpls netns init function in case of failure. If register_net_sysctl fails then we need to free the ctl_table. Fixes: 7720c01f ("mpls: Add a sysctl to control the size of the mpls label table") Signed-off-by:
-
David Ahern authored
TOS is another key aspect of the lookup passed to fib_validate_source. Add it to the tracepoint. Signed-off-by:
-
Alexei Starovoitov authored
To fix build errors: kernel/built-in.o: In function `bpf_trace_printk': bpf_trace.c:(.text+0x11a254): undefined reference to `strncpy_from_unsafe' kernel/built-in.o: In function `fetch_memory_string': trace_kprobe.c:(.text+0x11acf8): undefined reference to `strncpy_from_unsafe' move strncpy_from_unsafe() next to probe_kernel_read/write() which use the same memory access style. Reported-by:
Guenter Roeck <linux@roeck-us.net> Fixes: 1a6877b9 ("lib: introduce strncpy_from_unsafe()") Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
David S. Miller authored
Daniel Borkmann says: ==================== tcp: receive-side per route dctcp handling Original cover letter: Currently, the following case doesn't use DCTCP, even if it should: - responder has f.e. cubic as system wide default - 'ip route congctl dctcp $src' was set Then, DCTCP is NOT used if a DCTCP sender attempts to connect from a host in the $src range: ECT(0) is set, but listen_sk is not dctcp, so we fail the INET_ECN_is_not_ect sanity check. We also have to examine the dst used for the SYN/ACK reply to make this case work. In order to minimize additional cost, store the 'ecn is must have' information is the dst_features field. The set targets -next instead of -net since this doesn't seem to be a serious bug and to give the change more soak time until it hits linus tree. v1 -> v2: - Addressed Dave's feedback, not exposing any bits to user space - Added patch 3 to reject incorrect configurations - Rest as is, rebased and retested ==================== Signed-off-by: -
Daniel Borkmann authored
Currently, the following case doesn't use DCTCP, even if it should: A responder has f.e. Cubic as system wide default, but for a specific route to the initiating host, DCTCP is being set in RTAX_CC_ALGO. The initiating host then uses DCTCP as congestion control, but since the initiator sets ECT(0), tcp_ecn_create_request() doesn't set ecn_ok, and we have to fall back to Reno after 3WHS completes. We were thinking on how to solve this in a minimal, non-intrusive way without bloating tcp_ecn_create_request() needlessly: lets cache the CA ecn option flag in RTAX_FEATURES. In other words, when ECT(0) is set on the SYN packet, set ecn_ok=1 iff route RTAX_FEATURES contains the unexposed (internal-only) DST_FEATURE_ECN_CA. This allows to only do a single metric feature lookup inside tcp_ecn_create_request(). Joint work with Florian Westphal. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Daniel Borkmann authored
Feature bits that are invalid should not be accepted by the kernel, only the lower 4 bits may be configured, but not the remaining ones. Even from these 4, 2 of them are unused. Signed-off-by:
-
Daniel Borkmann authored
Reduce the identation a bit, there's no need to artificically have it increased. Signed-off-by:
-
Florian Westphal authored
fib_create_info() is already quite large, so before adding more code to the metrics section move that to a helper, similar to ip6_convert_metrics. Suggested-by:
-
