- 20 Oct, 2017 6 commits
-
-
Arnd Bergmann authored
After the change to the tp hash, we now get a build warning on 32-bit architectures: net/sched/cls_u32.c: In function 'tc_u_hash': net/sched/cls_u32.c:338:17: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] return hash_64((u64) tp->chain->block, U32_HASH_SHIFT); Using hash_ptr() instead of hash_64() lets us drop the cast and fixes the warning while still resulting in the same hash value. Fixes: 7fa9d974 ("net: sched: cls_u32: use block instead of q in tc_u_common") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
The tipc_alloc_conn() function never returns NULL, it returns error pointers, so I have fixed the check. Fixes: 14c04493 ("tipc: add ability to order and receive topology events in driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Simon Horman says: ==================== net: sh_eth: add R-Car Gen[12] fallback compatibility strings Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme is being adopted for drivers for Renesas SoCs. Changes since v1: * Correct typos in changelogs * Consistently use tabs for indentation in bindings document * Enhance readability of description of bindings usage ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
Implement fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme is being adopted for drivers for Renesas SoCs. Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The approach that has been consistently taken for other IP blocks is to name common code, compatibility strings and so on after R-Car Gen2. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
Rename structures describing R-Car SoCs as rcar_gen[12]_* rather than r8a77[79]x_*. This seems a little easier on the eyes. And will make things slightly cleaner in a follow-up patch that adds fallback-compatibility strings for these SoCs. Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The approach that has been consistently taken for other IP blocks is to name common code, compatibility strings and so on after R-Car Gen2. Also rename sh_eth_set_rate_r8a777x as sh_eth_set_rate_rcar as it it is used by the R-Car generations supported by the driver. This patch should have no run-time effect and is compile-tested only. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme is being adopted for drivers for Renesas SoCs. Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The approach that has been consistently taken for other IP blocks is to name common code, compatibility strings and so on after R-Car Gen2. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 19 Oct, 2017 24 commits
-
-
Stephen Hemminger authored
dql_init always returned 0, and the only place that uses it in network core code didn't care about the return value anyway. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Acked-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced the "NOBREAK" comment with a "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by: Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
NULL check before freeing functions like kfree is not needed. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by: Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Thomas Falcon says: ==================== ibmvnic: Enable SG and TSO feature support This patch set is fairly straightforward. The first patch enables scatter-gather support in the ibmvnic driver. The following patch then enables the TCP Segmentation offload feature. The final patch allows users to enable or disable net device features using ethtool. Enabling SG and TSO grants a large increase in throughput with TX speed increasing from 1Gb/s to 9Gb/s in our initial test runs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Falcon authored
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Falcon authored
This patch enables TSO support. It includes additional buffers reserved exclusively for large packets. Throughput is greatly increased with TSO enabled, from about 1 Gb/s to 9 Gb/s on our test systems. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Falcon authored
This patch enables scatter gather support. Since there is no HW/FW scatter-gather support at this time, the driver needs to loop through each fragment and copy it to a contiguous, pre-mapped buffer entry. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
syzkaller hit the WARN() in tun_get_user(), providing skb with payload in fragments only, and nothing in skb->head GRO layer is fine with this, so relax the check. Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
The pointer opt has a null check however before for this check opt is dereferenced when len is initialized, hence we potentially have a null pointer deference on opt. Avoid this by checking for a null opt before dereferencing it. Detected by CoverityScan, CID#1458234 ("Dereference before null check") Fixes: 4e8b86c0 ("mqprio: Introduce new hardware offload mode and shaper in mqprio") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
There is a problem when we do: sequence = pkg->hdr.length_sn & TBIP_HDR_SN_MASK; sequence >>= TBIP_HDR_SN_SHIFT; TBIP_HDR_SN_SHIFT is 27, and right shifting a u8 27 bits is always going to result in zero. The fix is to declare these variables as u32. Fixes: e69b6c02 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
The problematic code looks like this: res_seq = res_hdr->xd_hdr.length_sn & TB_XDOMAIN_SN_MASK; res_seq >>= TB_XDOMAIN_SN_SHIFT; TB_XDOMAIN_SN_SHIFT is 27, and right shifting a u8 27 bits is always going to result in zero. The fix is to declare these variables as u32. Fixes: d1ff7024 ("thunderbolt: Add support for XDomain discovery protocol") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Netanel Belgazal says: ==================== update ENA driver to releawse 1.3.0 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
Add a new statistic to ethtool stats that show the number of packets without transmit acknowledgement from ENA device. Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
Remove ena_device_io_suspend/resume() methods Those methods were intend to be used by the device to trigger suspend/resume but eventually it was dropped. Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
The ena admin commands timeout is in resolutions of 100ms. Therefore, When the driver works in polling mode, it sleeps for 100ms each time. The overall boot time of the ENA driver is ~1.5 sec. To reduce the boot time, This change modifies the granularity of the sleeps to 5ms. This change improves the boot time to 220ms. Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Netanel Belgazal authored
ENA driver was developed by developers from Annapurna Labs. Annapurna Labs was acquired by Amazon and the company's domain (@annapurnalabs.com) will become deprecated soon. Update the email addresses of the maintainers to the alternative amazon emails (@amazon.com) Signed-off-by: Netanel Belgazal <netanel@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michal Kalderon authored
Out of order flow is not working for iWARP. This patch got cut out from initial series that added out of order support for iWARP. Make out of order code common for iWARP and iSCSI. Add new configuration option CONFIG_QED_OOO. Set by qedr and qedi Kconfigs. Fixes: d1abfd0b ("qed: Add iWARP out of order support") Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by: Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
When using tc qdisc, dcb_ops->setup_tc is used to tell hclge_dcb module to do the tm related setup. Only TC_MQPRIO_MODE_CHANNEL offload mode is supported. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This patch reverts earlier commit b13ba1b8 ("macvlan: forbid L2 fowarding offload for macvtap"). The reason for reverting this is because the original patch no longer fixes what it previously did as the underlying structure has changed for macvtap. Specifically macvtap originally pulled packets directly off of the lowerdev. However in commit 6acf54f1 ("macvtap: Add support of packet capture on macvtap device.") that code was changed and instead macvtap would listen directly on the macvtap device itself instead of the lower device. As such, the L2 forwarding offload should now be able to provide a performance advantage of skipping the checks on the lower dev while not introducing any sort of regression. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2017-10-17 This series contains updates to i40e and ethtool. Alan provides most of the changes in this series which are mainly fixes and cleanups. Renamed the ethtool "cmd" variable to "ks", since the new ethtool API passes us ksettings structs instead of command structs. Cleaned up an ifdef that was not accomplishing anything. Added function header comments to provide better documentation. Fixed two issues in i40e_get_link_ksettings(), by calling ethtool_link_ksettings_zero_link_mode() to ensure the advertising and link masks are cleared before we start setting bits. Cleaned up and fixed code comments which were incorrect. Separated the setting of autoneg in i40e_phy_types_to_ethtool() into its own conditional to clarify what PHYs support and advertise autoneg, and makes it easier to add new PHY types in the future. Added ethtool functionality to intersect two link masks together to find the common ground between them. Overhauled i40e to ensure that the new ethtool API macros are being used, instead of the old ones. Fixed the usage of unsigned 64-bit division which is not supported on all architectures. Sudheer adds support for 25G Active Optical Cables (AOC) and Active Copper Cables (ACC) PHY types. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 18 Oct, 2017 10 commits
-
-
Eric Dumazet authored
I tried to hard avoiding a call to rb_first() (via tcp_rtx_queue_head) in tcp_xmit_retransmit_queue(). But this was probably too bold. Quoting Yuchung : We might miss re-arming the RTO if tp->retransmit_skb_hint is not NULL. This can happen when RACK marks the first packet lost again and resets tp->retransmit_skb_hint for example (tcp_rack_mark_skb_lost()) Fixes: 75c119af ("tcp: implement rb-tree based retransmit queue") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== bpf: move context info out of the verifier Daniel pointed out during the review of my previous patchset that the knowledge about context doesn't really belong directly in the verifier. This patch set takes a bit of a drastic approach to move the info out of there. I want to be able to use different set of verifier_ops for program analysis. To do that, I have to first move the test_run callback to a separate structure. Then verifier ops can be declared in the verifier directly and different sets can be picked for verification vs analysis. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Since we are now doing strict checking of what offloads may access, make sure skb->len is on that list. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Use the fact that verifier ops are now separate from program ops to define a separate set of callbacks for verification of already translated programs. Since we expect the analyzer ops to be defined only for a small subset of all program types initialize their array by hand (don't use linux/bpf_types.h). Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Since the verifier ops don't have to be associated with the program for its entire lifetime we can move it to verifier's struct bpf_verifier_env. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
struct bpf_verifier_ops contains both verifier ops and operations used later during program's lifetime (test_run). Split the runtime ops into a different structure. BPF_PROG_TYPE() will now append ## _prog_ops or ## _verifier_ops to the names. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ahern authored
Running perf in one window to capture tcp_retransmit_skb tracepoint: $ perf record -e tcp:tcp_retransmit_skb -a And causing a retransmission on an active TCP session (e.g., dropping packets in the receiver, changing MTU on the interface to 500 and back to 1500) triggers a panic: [ 58.543144] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 58.545300] IP: perf_trace_tcp_retransmit_skb+0xd0/0x145 [ 58.546770] PGD 0 P4D 0 [ 58.547472] Oops: 0000 [#1] SMP [ 58.548328] Modules linked in: vrf [ 58.549262] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc4+ #26 [ 58.551004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 58.554560] task: ffffffff81a0e540 task.stack: ffffffff81a00000 [ 58.555817] RIP: 0010:perf_trace_tcp_retransmit_skb+0xd0/0x145 [ 58.557137] RSP: 0018:ffff88003fc03d68 EFLAGS: 00010282 [ 58.558292] RAX: 0000000000000000 RBX: ffffe8ffffc0ec80 RCX: ffff880038543098 [ 58.559850] RDX: 0400000000000000 RSI: ffff88003fc03d70 RDI: ffff88003fc14b68 [ 58.561099] RBP: ffff88003fc03da8 R08: 0000000000000000 R09: ffffea0000d3224a [ 58.562005] R10: ffff88003fc03db8 R11: 0000000000000010 R12: ffff8800385428c0 [ 58.562930] R13: ffffe8ffffc0e478 R14: ffffffff81a93a40 R15: ffff88003d4f0c00 [ 58.563845] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 [ 58.564873] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 58.565613] CR2: 0000000000000008 CR3: 000000003d68f004 CR4: 00000000000606f0 [ 58.566538] Call Trace: [ 58.566865] <IRQ> [ 58.567140] __tcp_retransmit_skb+0x4ab/0x4c6 [ 58.567704] ? tcp_set_ca_state+0x22/0x3f [ 58.568231] tcp_retransmit_skb+0x14/0xa3 [ 58.568754] tcp_retransmit_timer+0x472/0x5e3 [ 58.569324] ? tcp_write_timer_handler+0x1e9/0x1e9 [ 58.569946] tcp_write_timer_handler+0x95/0x1e9 [ 58.570548] tcp_write_timer+0x2a/0x58 Check that daddr_cache is non-NULL before de-referencing. Fixes: e086101b ("tcp: add a tracepoint for tcp retransmission") Signed-off-by: David Ahern <dsahern@gmail.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in some cases I placed the "fall through" comment on its own line, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ahern authored
The compact form for IPv6 addresses is more user friendly than the full version. For example: compact: 2001:db8:1::1 full: 2001:0db8:0001:0000:0000:0000:0000:0004i Update the tcp tracepoint to show the compact form. Signed-off-by: David Ahern <dsahern@gmail.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-