- 09 Jan, 2017 40 commits
-
-
Niklas Söderlund authored
Tested on Gen2 r8a7791/Koelsch. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Niklas Söderlund authored
Add generic functionality to support Wake-on-LAN using MagicPacket which are supported by at least a few versions of sh_eth. Only add functionality for WoL, no specific sh_eth versions are marked to support WoL yet. WoL is enabled in the suspend callback by setting MagicPacket detection and disabling all interrupts expect MagicPacket. In the resume path the driver needs to reset the hardware to rearm the WoL logic, this prevents the driver from simply restoring the registers and to take advantage of that sh_eth was not suspended to reduce resume time. To reset the hardware the driver closes and reopens the device just like it would do in a normal suspend/resume scenario without WoL enabled, but it both closes and opens the device in the resume callback since the device needs to be open for WoL to work. One quirk needed for WoL is that the module clock needs to be prevented from being switched off by Runtime PM. To keep the clock alive the suspend callback need to call clk_enable() directly to increase the usage count of the clock. Then when Runtime PM decreases the clock usage count it won't reach 0 and be switched off. Signed-off-by:
-
Niklas Söderlund authored
This bit was wrongly named due to a typo, Sergei checked the SH7734/63 manuals and this bit should be named MPDE. Suggested-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
David S. Miller authored
Jesper Dangaard Brouer says: ==================== net: optimize ICMP-reply code path This patchset is optimizing the ICMP-reply code path, for ICMP packets that gets rate limited. A remote party can easily trigger this code path by sending packets to port number with no listening service. Generally the patchset moves the sysctl_icmp_msgs_per_sec ratelimit checking to earlier in the code path and removes an allocation. Use-case: The specific case I experienced this being a bottleneck is, sending UDP packets to a port with no listener, which obviously result in kernel replying with ICMP Destination Unreachable (type:3), Port Unreachable (code:3), which cause the bottleneck. After Eric and Paolo optimized the UDP socket code, the kernels PPS processing capabilities is lower for no-listen ports, than normal UDP sockets. This is bad for capacity planning when restarting a service. UDP no-listen benchmark 8xCPUs using pktgen_sample04_many_flows.sh: Baseline: 6.6 Mpps Patch: 14.7 Mpps Driver mlx5 at 50Gbit/s. ==================== Signed-off-by: -
Jesper Dangaard Brouer authored
It is possible to avoid the atomic operation in icmp{v6,}_xmit_lock, by checking the sysctl_icmp_msgs_per_sec ratelimit before these calls, as pointed out by Eric Dumazet, but the BH disabled state must be correct. The icmp_global_allow() call states it must be called with BH disabled. This protection was given by the calls icmp_xmit_lock and icmpv6_xmit_lock. Thus, split out local_bh_disable/enable from these functions and maintain it explicitly at callers. Suggested-by:Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jesper Dangaard Brouer authored
This patch split the global and per (inet)peer ICMP-reply limiter code, and moves the global limit check to earlier in the packet processing path. Thus, avoid spending cycles on ICMP replies that gets limited/suppressed anyhow. The global ICMP rate limiter icmp_global_allow() is a good solution, it just happens too late in the process. The kernel goes through the full route lookup (return path) for the ICMP message, before taking the rate limit decision of not sending the ICMP reply. Details: The kernels global rate limiter for ICMP messages got added in commit 4cdf507d ("icmp: add a global rate limitation"). It is a token bucket limiter with a global lock. It brilliantly avoids locking congestion by only updating when 20ms (HZ/50) were elapsed. It can then avoids taking lock when credit is exhausted (when under pressure) and time constraint for refill is not yet meet. Signed-off-by:
-
Jesper Dangaard Brouer authored
This reverts commit 9a99d4a5 ("icmp: avoid allocating large struct on stack"), because struct icmp_bxm no really a large struct, and allocating and free of this small 112 bytes hurts performance. Fixes: 9a99d4a5 ("icmp: avoid allocating large struct on stack") Signed-off-by:
-
David S. Miller authored
Merge tag 'rxrpc-rewrite-20170109' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== afs: Refcount afs_call struct These patches provide some tracepoints for AFS and fix a potential leak by adding refcounting to the afs_call struct. The patches are: (1) Add some tracepoints for logging incoming calls and monitoring notifications from AF_RXRPC and data reception. (2) Get rid of afs_wait_mode as it didn't turn out to be as useful as initially expected. It can be brought back later if needed. This clears some stuff out that I don't then need to fix up in (4). (3) Allow listen(..., 0) to be used to disable listening. This makes shutting down the AFS cache manager server in the kernel much easier and the accounting simpler as we can then be sure that (a) all preallocated afs_call structs are relesed and (b) no new incoming calls are going to be started. For the moment, listening cannot be reenabled. (4) Add refcounting to the afs_call struct to fix a potential multiple release detected by static checking and add a tracepoint to follow the lifecycle of afs_call objects. ==================== Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: Make dsa_switch_ops const This patch series allows us to annotate dsa_switch_ops with a const qualifier. ==================== Signed-off-by: -
Florian Fainelli authored
Now that we have properly encapsulated and made drivers utilize exported functions, we can switch dsa_switch_ops to be a annotated with const. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
In preparation for making struct dsa_switch_ops const, encapsulate it within a dsa_switch_driver which has a list pointer and a pointer to dsa_switch_ops. This allows us to take the list_head pointer out of dsa_switch_ops, which is written to by {un,}register_switch_driver. Signed-off-by: -
Florian Fainelli authored
Utilize the b53 exported functions to fill our bcm_sf2_ops structure, also making it clear what we utilize and what we specifically override. Signed-off-by:
-
Florian Fainelli authored
In preparation for making dsa_switch_ops const, export b53 operations utilized by other drivers such as bcm_sf2. Signed-off-by:
-
David S. Miller authored
Sergei Shtylyov says: ==================== sh_eth: "intgelligent checksum" related cleanups Here's a set of 2 patches against DaveM's 'net.git' repo, as they are based on a couple patches merged there recently; however, the patches are destined for 'net-next.git' (once 'net.git' gets merged there next time). I'm cleaning up the "intelligent checksum" related code (however, the driver only disables this feature for now, theres's no proper offload supprt yet). ==================== Signed-off-by: -
Sergei Shtylyov authored
The 'struct sh_eth_cpu_data' field indicating the "intelligent checksum" support was misnamed 'hw_crc' -- rename it to 'hw_checksum'. Signed-off-by:
-
Sergei Shtylyov authored
After checking all the available manuals, I have enough information to conclude that the 'shift_rd0' flag is only relevant for the Ether cores supporting so called "intelligent checksum" (and hence having CSMR) which is indicated by the 'hw_crc' flag. Since all the relevant SoCs now have both these flags set, we can at last get rid of the former flag... Signed-off-by:
-
-
Zefir Kurtisi authored
While in RUNNING state, phy_state_machine() checks for link changes by comparing phydev->link before and after calling phy_read_status(). This works as long as it is guaranteed that phydev->link is never changed outside the phy_state_machine(). If in some setups this happens, it causes the state machine to miss a link loss and remain RUNNING despite phydev->link being 0. This has been observed running a dsa setup with a process continuously polling the link states over ethtool each second (SNMPD RFC-1213 agent). Disconnecting the link on a phy followed by a ETHTOOL_GSET causes dsa_slave_get_settings() / dsa_slave_get_link_ksettings() to call phy_read_status() and with that modify the link status - and with that bricking the phy state machine. This patch adds a fail-safe check while in RUNNING, which causes to move to CHANGELINK when the link is gone and we are still RUNNING. Signed-off-by:
Zefir Kurtisi <zefir.kurtisi@neratec.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix dumping of nft_quota entries, from Pablo Neira Ayuso. 2) Fix out of bounds access in nf_tables discovered by KASAN, from Florian Westphal. 3) Fix IRQ enabling in dp83867 driver, from Grygorii Strashko. 4) Fix unicast filtering in be2net driver, from Ivan Vecera. 5) tg3_get_stats64() can race with driver close and ethtool reconfigurations, fix from Michael Chan. 6) Fix error handling when pass limit is reached in bpf code gen on x86. From Daniel Borkmann. 7) Don't clobber switch ops and use proper MDIO nested reads and writes in bcm_sf2 driver, from Florian Fainelli. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (21 commits) net: dsa: bcm_sf2: Utilize nested MDIO read/write net: dsa: bcm_sf2: Do not clobber b53_switch_ops net: stmmac: fix maxmtu assignment to be within valid range bpf: change back to orig prog on too many passes tg3: Fix race condition in tg3_get_stats64(). be2net: fix unicast list filling be2net: fix accesses to unicast list netlabel: add CALIPSO to the list of built-in protocols vti6: fix device register to report IFLA_INFO_KIND net: phy: dp83867: fix irq generation amd-xgbe: Fix IRQ processing when running in single IRQ mode sh_eth: R8A7740 supports packet shecksumming sh_eth: fix EESIPR values for SH77{34|63} r8169: fix the typo in the comment nl80211: fix sched scan netlink socket owner destruction bridge: netfilter: Fix dropping packets that moving through bridge interface netfilter: ipt_CLUSTERIP: check duplicate config when initializing netfilter: nft_payload: mangle ckecksum if NFT_PAYLOAD_L4CSUM_PSEUDOHDR is set netfilter: nf_tables: fix oob access netfilter: nft_queue: use raw_smp_processor_id() ... -
David S. Miller authored
Joao Pinto says: ==================== adding new glue driver dwmac-dwc-qos-eth This patch set contains the porting of the synopsys/dwc_eth_qos.c driver to the stmmac structure. This operation resulted in the creation of a new platform glue driver called dwmac-dwc-qos-eth which was based in the dwc_eth_qos as is. dwmac-dwc-qos-eth inherited dwc_eth_qos DT bindings, to assure that current and old users can continue to use it as before. We can see this driver as being deprecated, since all new development will be done in stmmac. Please check each patch for implementation details. ==================== Tested-by:
Niklas Cassel <niklas.cassel@axis.com> Reviewed-by:
Lars Persson <larper@axis.com> Acked-by:
Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by:
-
jpinto authored
This patch adds a new glue driver called dwmac-dwc-qos-eth which was based in the dwc_eth_qos as is. To assure retro-compatibility a slight tweak was also added to stmmac_platform. Signed-off-by:
Joao Pinto <jpinto@synopsys.com> Tested-by:
-
jpinto authored
This patch moves stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to the plat_stmmacenet_data structure. It also moves these platform variables initialization to stmmac_platform. This was done for two reasons: a) If PCI is used, platform related code is being executed in stmmac_main resulting in warnings that have no sense and conceptually was not right b) stmmac as a synopsys reference ethernet driver stack will be hosting more and more drivers to its structure like synopsys/dwc_eth_qos.c. These drivers have their own DT bindings that are not compatible with stmmac's. One of the most important are the clock names, and so they need to be parsed in the glue logic and initialized there, and that is the main reason why the clocks were passed to the platform structure. Signed-off-by:
-
jpinto authored
This patch adds a new parameter to the stmmac DT: snps,en-tx-lpi-clockgating. It was ported from synopsys/dwc_eth_qos.c and it is useful if lpi tx clock gating is needed by stmmac users also. Signed-off-by:
-
Tobias Regnery authored
The code to handle rx checksumming was in the driver since its introduction but for reasons unknown the feature flag was left out. Now it is possible to enable this feature with ethtool. Tested on my AR8161 ethernet card, there are no regressions observed in netperf if this feature is enabled. Signed-off-by:
Tobias Regnery <tobias.regnery@gmail.com> Signed-off-by:
-
David S. Miller authored
Davide Caratti says: ==================== net/sched: act_csum: add support for SCTP checksum This series extends current act_csum functionality to allow computation of SCTP checksums. Patch 1 ensures LIBCRC32C will be selected if NET_ACT_CSUM is selected. Patch 2 extends act_csum to handle IPPROTO_SCTP protocol in IPv4/IPv6 header, and eventually compute the CRC32c value. v2: - style fix in tc_csum.h - avoid nested if statement in act_csum.c ==================== Signed-off-by: -
Davide Caratti authored
modify act_csum to compute crc32c on IPv4/IPv6 packets having SCTP in their payload, and extend UAPI definitions accordingly. Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Davide Caratti authored
LIBCRC32C is needed to compute crc32c on SCTP packets. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: small driver update This patchset contains various small "non-net" fixes and enhancements. ==================== Signed-off-by: -
Yotam Gigi authored
As ENOTSUPP is specific to NFS, change the return error value to EOPNOTSUPP in various places in the mlxsw driver. Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Yotam Gigi authored
Fix the order of the free directives to match the port init function Signed-off-by:
-
Yotam Gigi authored
Currently, the mlxsw spectrum driver only supports offloading the matchall classifier together with the mirred action. To allow more matchall tc offloads, make the code symmetric so that it can be easily extended later on for other actions. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Elad Raz authored
Probably some copy-paste error from "int_msix" that caused "int_" prefix to appear in the comments for all "eq_" APIs. Signed-off-by:
Elad Raz <eladr@mellanox.com> Acked-by:
-
Elad Raz authored
The "err" variable is been checked, return always 0. Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Signed-off-by:
-
Ivan Khoronzhuk authored
Allow to set number of descs close to possible values. In case of minimum limit it's equal to number of channels to be able to set at least one desc per channel. For maximum limit leave enough descs number for tx channels. Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
-
Alexandru Moise authored
This struct member is already initialized to zero upon root_ht's allocation via kzalloc(). Signed-off-by:
Alexandru Moise <00moses.alexander00@gmail.com> Signed-off-by:
-
David S. Miller authored
Jason A. Donenfeld says: ==================== Introduce The SipHash PRF This patch series introduces SipHash into the kernel. SipHash is a cryptographically secure PRF, which serves a variety of functions, and is introduced in patch #1. The following patch #2 introduces HalfSipHash, an optimization suitable for hash tables only. Finally, the last two patches in this series show two usages of the introduced siphash function family. It is expected that after this initial introduction, other usages will follow. Please read the extensive descriptions in patch #1 and patch #2 of what these functions do and the various levels of assurances. They're products of intense cryptographic research, and I believe they're suitable for the uses outlined herein. The use of SipHash is not limited to the networking subsystem -- indeed I would like to use it in other places too in the kernel. But after discussing with a few on this list and at Linus' suggestion, the initial import of these functions is coming through the networking tree. After these are merged, it will then be easier to expand use elsewhere. Changes v2->v3: - hsiphash keys now simply use an unsigned long, in order to avoid a cluttered ifdef and make it a bit more clear what's happening. - A typo in the documentation has been fixed. - The documentation has been augmented with an example relating to struct packing and passing. - The net_secret variable is now __read_mostly. Hopefully this is the last of the required revisions, and v3 can be merged into net-next. ==================== Signed-off-by: -
Jason A. Donenfeld authored
SHA1 is slower and less secure than SipHash, and so replacing syncookie generation with SipHash makes natural sense. Some BSDs have been doing this for several years in fact. The speedup should be similar -- and even more impressive -- to the speedup from the sequence number fix in this series. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Jason A. Donenfeld authored
This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the values directly to the short input convenience functions. 64-bit x86_64: [ 1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527 [ 1.717350] secure_tcp_sequence_number_md5# cycles: 92890502 [ 1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362 [ 1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526 32-bit x86: [ 1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892 [ 1.634219] secure_tcp_sequence_number_md5# cycles: 94732544 [ 1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384 [ 1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473 Signed-off-by:
-
Jason A. Donenfeld authored
HalfSipHash, or hsiphash, is a shortened version of SipHash, which generates 32-bit outputs using a weaker 64-bit key. It has *much* lower security margins, and shouldn't be used for anything too sensitive, but it could be used as a hashtable key function replacement, if the output is never exposed, and if the security requirement is not too high. The goal is to make this something that performance-critical jhash users would be willing to use. On 64-bit machines, HalfSipHash1-3 is slower than SipHash1-3, so we alias SipHash1-3 to HalfSipHash1-3 on those systems. 64-bit x86_64: [ 0.509409] test_siphash: SipHash2-4 cycles: 4049181 [ 0.510650] test_siphash: SipHash1-3 cycles: 2512884 [ 0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920 [ 0.512904] test_siphash: JenkinsHash cycles: 978267 So, we map hsiphash() -> SipHash1-3 32-bit x86: [ 0.509868] test_siphash: SipHash2-4 cycles: 14812892 [ 0.513601] test_siphash: SipHash1-3 cycles: 9510710 [ 0.515263] test_siphash: HalfSipHash1-3 cycles: 3856157 [ 0.515952] test_siphash: JenkinsHash cycles: 1148567 So, we map hsiphash() -> HalfSipHash1-3 hsiphash() is roughly 3 times slower than jhash(), but comes with a considerable security improvement. Signed-off-by:
Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Signed-off-by:
-
Jason A. Donenfeld authored
SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first usage: There are a variety of attacks known as "hashtable poisoning" in which an attacker forms some data such that the hash of that data will be the same, and then preceeds to fill up all entries of a hashbucket. This is a realistic and well-known denial-of-service vector. Currently hashtables use jhash, which is fast but not secure, and some kind of rotating key scheme (or none at all, which isn't good). SipHash is meant as a replacement for jhash in these cases. There are a modicum of places in the kernel that are vulnerable to hashtable poisoning attacks, either via userspace vectors or network vectors, and there's not a reliable mechanism inside the kernel at the moment to fix it. The first step toward fixing these issues is actually getting a secure primitive into the kernel for developers to use. Then we can, bit by bit, port things over to it as deemed appropriate. While SipHash is extremely fast for a cryptographically secure function, it is likely a bit slower than the insecure jhash, and so replacements will be evaluated on a case-by-case basis based on whether or not the difference in speed is negligible and whether or not the current jhash usage poses a real security risk. For the second usage: A few places in the kernel are using MD5 or SHA1 for creating secure sequence numbers, syn cookies, port numbers, or fast random numbers. SipHash is a faster and more fitting, and more secure replacement for MD5 in those situations. Replacing MD5 and SHA1 with SipHash for these uses is obvious and straight-forward, and so is submitted along with this patch series. There shouldn't be much of a debate over its efficacy. Dozens of languages are already using this internally for their hash tables and PRFs. Some of the BSDs already use this in their kernels. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by:
-
