summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-10-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfJakub Kicinski12-19/+37
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Update debugging in IPVS tcp protocol handler to make it easier to understand, from longguang.yue 2) Update TCP tracker to deal with keepalive packet after re-registration, from Franceso Ruggeri. 3) Missing IP6SKB_FRAGMENTED from netfilter fragment reassembly, from Georg Kohmann. 4) Fix bogus packet drop in ebtables nat extensions, from Thimothee Cocault. 5) Fix typo in flowtable documentation. 6) Reset skb timestamp in nft_fwd_netdev. ==================== Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski16-102/+426
Daniel Borkmann says: ==================== pull-request: bpf 2020-10-22 1) Fix enforcing NULL check in verifier for new helper return types of RET_PTR_TO_{BTF_ID,MEM_OR_BTF_ID}_OR_NULL, from Martin KaFai Lau. 2) Fix bpf_redirect_neigh() helper API before it becomes frozen by adding nexthop information as argument, from Toke Høiland-Jørgensen. 3) Guard & fix compilation of bpf_tail_call_static() when __bpf__ arch is not defined by compiler or clang too old, from Daniel Borkmann. 4) Remove misplaced break after return in attach_type_to_prog_type(), from Tom Rix. ==================== Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-22netfilter: nf_fwd_netdev: clear timestamp in forwarding pathPablo Neira Ayuso2-0/+2
Similar to 7980d2eabde8 ("ipvs: clear skb->tstamp in forwarding path"). fq qdisc requires tstamp to be cleared in forwarding path. Fixes: 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-21ibmvnic: save changed mac address to adapter->mac_addrLijun Pan1-0/+5
After mac address change request completes successfully, the new mac address need to be saved to adapter->mac_addr as well as netdev->dev_addr. Otherwise, adapter->mac_addr still holds old data. Fixes: 62740e97881c ("net/ibmvnic: Update MAC address settings after adapter reset") Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20201020223919.46106-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21selftests: mptcp: depends on built-in IPv6Matthieu Baerts1-0/+1
Recently, CONFIG_MPTCP_IPV6 no longer selects CONFIG_IPV6. As a consequence, if CONFIG_MPTCP_IPV6=y is added to the kconfig, it will no longer ensure CONFIG_IPV6=y. If it is not enabled, CONFIG_MPTCP_IPV6 will stay disabled and selftests will fail. We also need CONFIG_IPV6 to be built-in. For more details, please see commit 0ed37ac586c0 ("mptcp: depends on IPV6 but not as a module"). Note that 'make kselftest-merge' will take all 'config' files found in 'tools/testsing/selftests'. Because some of them already set CONFIG_IPV6=y, MPTCP selftests were still passing. But they will fail if MPTCP selftests are launched manually after having executed this command to prepare the kernel config: ./scripts/kconfig/merge_config.sh -m .config \ ./tools/testing/selftests/net/mptcp/config Fixes: 010b430d5df5 ("mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting it") Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Link: https://lore.kernel.org/r/20201021155549.933731-1-matthieu.baerts@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21Revert "virtio-net: ethtool configurable RXCSUM"Michael S. Tsirkin1-36/+12
This reverts commit 3618ad2a7c0e78e4258386394d5d5f92a3dbccf8. When control vq is not negotiated, that commit causes a crash: [ 72.229171] kernel BUG at drivers/net/virtio_net.c:1667! [ 72.230266] invalid opcode: 0000 [#1] PREEMPT SMP [ 72.231172] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8-02934-g3618ad2a7c0e7 #1 [ 72.231172] EIP: virtnet_send_command+0x120/0x140 [ 72.231172] Code: 00 0f 94 c0 8b 7d f0 65 33 3d 14 00 00 00 75 1c 8d 65 f4 5b 5e 5f 5d c3 66 90 be 01 00 00 00 e9 6e ff ff ff 8d b6 00 +00 00 00 <0f> 0b e8 d9 bb 82 00 eb 17 8d b4 26 00 00 00 00 8d b4 26 00 00 00 [ 72.231172] EAX: 0000000d EBX: f72895c0 ECX: 00000017 EDX: 00000011 [ 72.231172] ESI: f7197800 EDI: ed69bd00 EBP: ed69bcf4 ESP: ed69bc98 [ 72.231172] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246 [ 72.231172] CR0: 80050033 CR2: 00000000 CR3: 02c84000 CR4: 000406f0 [ 72.231172] Call Trace: [ 72.231172] ? __virt_addr_valid+0x45/0x60 [ 72.231172] ? ___cache_free+0x51f/0x760 [ 72.231172] ? kobject_uevent_env+0xf4/0x560 [ 72.231172] virtnet_set_guest_offloads+0x4d/0x80 [ 72.231172] virtnet_set_features+0x85/0x120 [ 72.231172] ? virtnet_set_guest_offloads+0x80/0x80 [ 72.231172] __netdev_update_features+0x27a/0x8e0 [ 72.231172] ? kobject_uevent+0xa/0x20 [ 72.231172] ? netdev_register_kobject+0x12c/0x160 [ 72.231172] register_netdevice+0x4fe/0x740 [ 72.231172] register_netdev+0x1c/0x40 [ 72.231172] virtnet_probe+0x728/0xb60 [ 72.231172] ? _raw_spin_unlock+0x1d/0x40 [ 72.231172] ? virtio_vdpa_get_status+0x1c/0x20 [ 72.231172] virtio_dev_probe+0x1c6/0x271 [ 72.231172] really_probe+0x195/0x2e0 [ 72.231172] driver_probe_device+0x26/0x60 [ 72.231172] device_driver_attach+0x49/0x60 [ 72.231172] __driver_attach+0x46/0xc0 [ 72.231172] ? device_driver_attach+0x60/0x60 [ 72.231172] bus_add_driver+0x197/0x1c0 [ 72.231172] driver_register+0x66/0xc0 [ 72.231172] register_virtio_driver+0x1b/0x40 [ 72.231172] virtio_net_driver_init+0x61/0x86 [ 72.231172] ? veth_init+0x14/0x14 [ 72.231172] do_one_initcall+0x76/0x2e4 [ 72.231172] ? rdinit_setup+0x2a/0x2a [ 72.231172] do_initcalls+0xb2/0xd5 [ 72.231172] kernel_init_freeable+0x14f/0x179 [ 72.231172] ? rest_init+0x100/0x100 [ 72.231172] kernel_init+0xd/0xe0 [ 72.231172] ret_from_fork+0x1c/0x30 [ 72.231172] Modules linked in: [ 72.269563] ---[ end trace a6ebc4afea0e6cb1 ]--- The reason is that virtnet_set_features now calls virtnet_set_guest_offloads unconditionally, it used to only call it when there is something to configure. If device does not have a control vq, everything breaks. Revert the original commit for now. Cc: Tonghao Zhang <xiangxia.m.yue@gmail.com> Fixes: 3618ad2a7c0e7 ("virtio-net: ethtool configurable RXCSUM") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20201021142944.13615-1-mst@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21rtnetlink: fix data overflow in rtnl_calcit()Di Zhu2-8/+7
"ip addr show" command execute error when we have a physical network card with a large number of VFs The return value of if_nlmsg_size() in rtnl_calcit() will exceed range of u16 data type when any network cards has a larger number of VFs. rtnl_vfinfo_size() will significant increase needed dump size when the value of num_vfs is larger. Eventually we get a wrong value of min_ifinfo_dump_size because of overflow which decides the memory size needed by netlink dump and netlink_dump() will return -EMSGSIZE because of not enough memory was allocated. So fix it by promoting min_dump_alloc data type to u32 to avoid whole netlink message size overflow and it's also align with the data type of struct netlink_callback{}.min_dump_alloc which is assigned by return value of rtnl_calcit() Signed-off-by: Di Zhu <zhudi21@huawei.com> Link: https://lore.kernel.org/r/20201021020053.1401-1-zhudi21@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21net: ethernet: mtk-star-emac: select REGMAP_MMIOBartosz Golaszewski1-0/+1
The driver depends on mmio regmap API but doesn't select the appropriate Kconfig option. This fixes it. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setupXie He1-0/+1
This driver calls ether_setup to set up the network device. The ether_setup function would add the IFF_TX_SKB_SHARING flag to the device. This flag indicates that it is safe to transmit shared skbs to the device. However, this is not true. This driver may pad the frame (in eth_tx) before transmission, so the skb may be modified. Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared") Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-21net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC deviceXie He1-1/+9
The hdlc_rcv function is used as hdlc_packet_type.func to process any skb received in the kernel with skb->protocol == htons(ETH_P_HDLC). The purpose of this function is to provide second-stage processing for skbs not assigned a "real" L3 skb->protocol value in the first stage. This function assumes the device from which the skb is received is an HDLC device (a device created by this module). It assumes that netdev_priv(dev) returns a pointer to "struct hdlc_device". However, it is possible that some driver in the kernel (not necessarily in our control) submits a received skb with skb->protocol == htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would still be received by hdlc_rcv. This will cause problems. hdlc_rcv should be able to recognize and drop invalid skbs. It should first make sure "dev" is actually an HDLC device, before starting its processing. This patch adds this check to hdlc_rcv. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-22bpf, libbpf: Guard bpf inline asm from bpf_tail_call_staticDaniel Borkmann2-4/+6
Yaniv reported a compilation error after pulling latest libbpf: [...] ../libbpf/src/root/usr/include/bpf/bpf_helpers.h:99:10: error: unknown register name 'r0' in asm : "r0", "r1", "r2", "r3", "r4", "r5"); [...] The issue got triggered given Yaniv was compiling tracing programs with native target (e.g. x86) instead of BPF target, hence no BTF generated vmlinux.h nor CO-RE used, and later llc with -march=bpf was invoked to compile from LLVM IR to BPF object file. Given that clang was expecting x86 inline asm and not BPF one the error complained that these regs don't exist on the former. Guard bpf_tail_call_static() with defined(__bpf__) where BPF inline asm is valid to use. BPF tracing programs on more modern kernels use BPF target anyway and thus the bpf_tail_call_static() function will be available for them. BPF inline asm is supported since clang 7 (clang <= 6 otherwise throws same above error), and __bpf_unreachable() since clang 8, therefore include the latter condition in order to prevent compilation errors for older clang versions. Given even an old Ubuntu 18.04 LTS has official LLVM packages all the way up to llvm-10, I did not bother to special case the __bpf_unreachable() inside bpf_tail_call_static() further. Also, undo the sockex3_kern's use of bpf_tail_call_static() sample given they still have the old hacky way to even compile networking progs with native instead of BPF target so bpf_tail_call_static() won't be defined there anymore. Fixes: 0e9f6841f664 ("bpf, libbpf: Add bpf_tail_call_static helper for bpf programs") Reported-by: Yaniv Agman <yanivagman@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Tested-by: Yaniv Agman <yanivagman@gmail.com> Link: https://lore.kernel.org/bpf/CAMy7=ZUk08w5Gc2Z-EKi4JFtuUCaZYmE4yzhJjrExXpYKR4L8w@mail.gmail.com Link: https://lore.kernel.org/bpf/20201021203257.26223-1-daniel@iogearbox.net
2020-10-22bpf, selftests: Extend test_tc_redirect to use modified bpf_redirect_neigh()Toke Høiland-Jørgensen3-5/+173
This updates the test_tc_neigh prog in selftests to use the new syntax of bpf_redirect_neigh(). To exercise the helper both with and without the optional parameter, add an additional test_tc_neigh_fib test program, which does a bpf_fib_lookup() followed by a call to bpf_redirect_neigh() instead of looking up the ifindex in a map. Update the test_tc_redirect.sh script to run both versions of the test, and while we're add it, fix it to work on systems that have a consolidated dual-stack 'ping' binary instead of separate ping/ping6 versions. Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/160322915724.32199.17530068594636950447.stgit@toke.dk
2020-10-22bpf: Fix bpf_redirect_neigh helper api to support supplying nexthopToke Høiland-Jørgensen5-67/+145
Based on the discussion in [0], update the bpf_redirect_neigh() helper to accept an optional parameter specifying the nexthop information. This makes it possible to combine bpf_fib_lookup() and bpf_redirect_neigh() without incurring a duplicate FIB lookup - since the FIB lookup helper will return the nexthop information even if no neighbour is present, this can simply be passed on to bpf_redirect_neigh() if bpf_fib_lookup() returns BPF_FIB_LKUP_RET_NO_NEIGH. Thus fix & extend it before helper API is frozen. [0] https://lore.kernel.org/bpf/393e17fc-d187-3a8d-2f0d-a627c7c63fca@iogearbox.net/ Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/bpf/160322915615.32199.1187570224032024535.stgit@toke.dk
2020-10-21mptcp: depends on IPV6 but not as a moduleMatthieu Baerts1-1/+1
Like TCP, MPTCP cannot be compiled as a module. Obviously, MPTCP IPv6' support also depends on CONFIG_IPV6. But not all functions from IPv6 code are exported. To simplify the code and reduce modifications outside MPTCP, it was decided from the beginning to support MPTCP with IPv6 only if CONFIG_IPV6 was built inlined. That's also why CONFIG_MPTCP_IPV6 was created. More modifications are needed to support CONFIG_IPV6=m. Even if it was not explicit, until recently, we were forcing CONFIG_IPV6 to be built-in because we had "select IPV6" in Kconfig. Now that we have "depends on IPV6", we have to explicitly set "IPV6=y" to force CONFIG_IPV6 not to be built as a module. In other words, we can now only have CONFIG_MPTCP_IPV6=y if CONFIG_IPV6=y. Note that the new dependency might hide the fact IPv6 is not supported in MPTCP even if we have CONFIG_IPV6=m. But selecting IPV6 like we did before was forcing it to be built-in while it was maybe not what the user wants. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: 010b430d5df5 ("mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting it") Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20201021105154.628257-1-matthieu.baerts@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20sfc: move initialisation of efx->filter_sem to efx_init_struct()Edward Cree2-1/+1
efx_probe_filters() has not been called yet when EF100 calls into efx_mcdi_filter_table_probe(), for which it wants to take the filter_sem. Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by: Edward Cree <ecree@solarflare.com> Link: https://lore.kernel.org/r/24fad43e-887d-051e-25e3-506f23f63abf@solarflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20mpls: load mpls_gso after mpls_iptunnelAlexander Ovechkin1-0/+1
mpls_iptunnel is used only for mpls encapsuation, and if encaplusated packet is larger than MTU we need mpls_gso for segmentation. Signed-off-by: Alexander Ovechkin <ovov@yandex-team.ru> Acked-by: Dmitry Yakunin <zeil@yandex-team.ru> Reviewed-by: David Ahern <dsahern@gmail.com> Link: https://lore.kernel.org/r/20201020114333.26866-1-ovov@yandex-team.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net/sched: act_tunnel_key: fix OOB write in case of IPv6 ERSPAN tunnelsDavide Caratti1-1/+1
the following command # tc action add action tunnel_key \ > set src_ip 2001:db8::1 dst_ip 2001:db8::2 id 10 erspan_opts 1:6789:0:0 generates the following splat: BUG: KASAN: slab-out-of-bounds in tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key] Write of size 4 at addr ffff88813f5f1cc8 by task tc/873 CPU: 2 PID: 873 Comm: tc Not tainted 5.9.0+ #282 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x99/0xcb print_address_description.constprop.7+0x1e/0x230 kasan_report.cold.13+0x37/0x7c tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key] tunnel_key_init+0x160c/0x1f40 [act_tunnel_key] tcf_action_init_1+0x5b5/0x850 tcf_action_init+0x15d/0x370 tcf_action_add+0xd9/0x2f0 tc_ctl_action+0x29b/0x3a0 rtnetlink_rcv_msg+0x341/0x8d0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f872a96b338 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffffe367518 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000005f8f5aed RCX: 00007f872a96b338 RDX: 0000000000000000 RSI: 00007ffffe367580 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000001c R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000686760 R14: 0000000000000601 R15: 0000000000000000 Allocated by task 873: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.7+0xc1/0xd0 __kmalloc+0x151/0x310 metadata_dst_alloc+0x20/0x40 tunnel_key_init+0xfff/0x1f40 [act_tunnel_key] tcf_action_init_1+0x5b5/0x850 tcf_action_init+0x15d/0x370 tcf_action_add+0xd9/0x2f0 tc_ctl_action+0x29b/0x3a0 rtnetlink_rcv_msg+0x341/0x8d0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88813f5f1c00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 200 bytes inside of 256-byte region [ffff88813f5f1c00, ffff88813f5f1d00) The buggy address belongs to the page: page:0000000011b48a19 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13f5f0 head:0000000011b48a19 order:1 compound_mapcount:0 flags: 0x17ffffc0010200(slab|head) raw: 0017ffffc0010200 0000000000000000 0000000d00000001 ffff888107c43400 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88813f5f1b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813f5f1c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88813f5f1c80: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc ^ ffff88813f5f1d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813f5f1d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc using IPv6 tunnels, act_tunnel_key allocates a fixed amount of memory for the tunnel metadata, but then it expects additional bytes to store tunnel specific metadata with tunnel_key_copy_opts(). Fix the arguments of __ipv6_tun_set_dst(), so that 'md_size' contains the size previously computed by tunnel_key_get_opts_len(), like it's done for IPv4 tunnels. Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key") Reported-by: Shuang Li <shuali@redhat.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Link: https://lore.kernel.org/r/36ebe969f6d13ff59912d6464a4356fe6f103766.1603231100.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net/sched: act_gate: Unlock ->tcfa_lock in tc_setup_flow_action()Guillaume Nault1-1/+1
We need to jump to the "err_out_locked" label when tcf_gate_get_entries() fails. Otherwise, tc_setup_flow_action() exits with ->tcfa_lock still held. Fixes: d29bdd69ecdd ("net: schedule: add action gate offloading") Signed-off-by: Guillaume Nault <gnault@redhat.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Link: https://lore.kernel.org/r/12f60e385584c52c22863701c0185e40ab08a7a7.1603207948.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net: dsa: bcm_sf2: make const array static, makes object smallerColin Ian King1-1/+1
Don't populate the const array rate_table on the stack but instead it static. Makes the object code smaller by 46 bytes. Before: text data bss dec hex filename 29812 3824 192 33828 8424 drivers/net/dsa/bcm_sf2.o After: text data bss dec hex filename 29670 3920 192 33782 83f6 drivers/net/dsa/bcm_sf2.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201020165029.56383-1-colin.king@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting itGeert Uytterhoeven1-1/+1
MPTCP_IPV6 selects IPV6, thus enabling an optional feature the user may not want to enable. Fix this by making MPTCP_IPV6 depend on IPV6, like is done for all other IPv6 features. Fixes: f870fa0b5768842c ("mptcp: Add MPTCP socket stubs") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20201020073839.29226-1-geert@linux-m68k.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net: chelsio: inline_crypto: fix Kconfig and build errorsRandy Dunlap1-0/+1
Fix build errors when TLS=m, TLS_TOE=y, and CRYPTO_DEV_CHELSIO_TLS=y. Having (tristate) CRYPTO_DEV_CHELSIO_TLS depend on (bool) TLS_TOE is not strong enough to prevent the bad combination of TLS=m and CRYPTO_DEV_CHELSIO_TLS=y, so add a dependency on TLS to prevent the problematic kconfig combination. Fixes these build errors: hppa-linux-ld: drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.o: in function `chtls_free_uld': drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.c:165: undefined reference to `tls_toe_unregister_device' hppa-linux-ld: drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.o: in function `chtls_register_dev': drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.c:204: undefined reference to `tls_toe_register_device' Fixes: 53b4414a7003 ("net/tls: allow compiling TLS TOE out") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20201019181059.22634-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20Merge branch 'chelsio-chtls-fix-inline-tls-bugs'Jakub Kicinski2-8/+16
Vinay Kumar Yadav says: ==================== chelsio/chtls: Fix inline tls bugs This series of patches fix following bugs in chelsio inline tls driver. Patch1: Fix incorrect socket lock. Patch2: correct netdevice for vlan interface. Patch3: Fix panic when server is listening on ipv6. Patch4: Fix panic when listen on multiadapter. Patch5: correct function return and return type. Patch6: Fix writing freed memory. ==================== Link: https://lore.kernel.org/r/20201019115025.24233-1-vinay.yadav@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: fix writing freed memoryVinay Kumar Yadav1-1/+0
When chtls_sock *csk is freed, same memory can be allocated to different csk in chtls_sock_create(). csk->cdev = NULL; statement might ends up modifying wrong csk, eventually causing kernel panic. removing (csk->cdev = NULL) statement as it is not required. Fixes: 3a0a97838923 ("crypto/chtls: Fix chtls crash in connection cleanup") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: correct function return and return typeVinay Kumar Yadav1-2/+2
csk_mem_free() should return true if send buffer is available, false otherwise. Fixes: 3b8305f5c844 ("crypto: chtls - wait for memory sendmsg, sendpage") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: Fix panic when listen on multiadapterVinay Kumar Yadav1-2/+8
Add the logic to compare net_device returned by ip_dev_find() with the net_device list in cdev->ports[] array and return net_device if matched else NULL. Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS") Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com> Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: fix panic when server is on ipv6Vinay Kumar Yadav1-3/+2
Netdev is filled in egress_dev when connection is established, If connection is closed before establishment, then egress_dev is NULL, Fix it using ip_dev_find() rather then extracting from egress_dev. Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS") Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com> Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: correct netdevice for vlan interfaceVinay Kumar Yadav1-0/+3
Check if netdevice is a vlan interface and find real vlan netdevice. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com> Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20chelsio/chtls: fix socket lockVinay Kumar Yadav1-0/+1
In chtls_sendpage() socket lock is released but not acquired, fix it by taking lock. Fixes: 36bedb3f2e5b ("crypto: chtls - Inline TLS record Tx") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in ↵Defang Bo1-1/+1
nfc_genl_fw_download() Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by the netlink client prior to accessing them.This prevents potential unhandled NULL pointer dereference exceptions which can be triggered by malicious user-mode programs, if they omit one or both of these attributes. Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler"). Fixes: 9674da8759df ("NFC: Add firmware upload netlink command") Signed-off-by: Defang Bo <bodefang@126.com> Link: https://lore.kernel.org/r/1603107538-4744-1-git-send-email-bodefang@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20mptcp: MPTCP_KUNIT_TESTS should depend on MPTCP instead of selecting itGeert Uytterhoeven1-3/+1
MPTCP_KUNIT_TESTS selects MPTCP, thus enabling an optional feature the user may not want to enable. Fix this by making the test depend on MPTCP instead. Fixes: a00a582203dbc43e ("mptcp: move crypto test to KUNIT") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20201019113240.11516-1-geert@linux-m68k.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20Merge branch 'init-ahmac-and-port-of-mptcp_options_received'Jakub Kicinski1-1/+2
Geliang Tang says: ==================== init ahmac and port of mptcp_options_received This patchset deals with initializations of mptcp_options_received's two fields, ahmac and port. ==================== Link: https://lore.kernel.org/r/cover.1603102503.git.geliangtang@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20mptcp: move mptcp_options_received's port initializationGeliang Tang1-1/+1
Move mptcp_options_received's port initialization from mptcp_parse_option to mptcp_get_options, put it together with the other fields initializations of mptcp_options_received. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20mptcp: initialize mptcp_options_received's ahmacGeliang Tang1-0/+1
Initialize mptcp_options_received's ahmac to zero, otherwise it will be a random number when receiving ADD_ADDR suboption with echo-flag=1. Fixes: 3df523ab582c5 ("mptcp: Add ADD_ADDR handling") Signed-off-by: Geliang Tang <geliangtang@gmail.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net/sched: act_ct: Fix adding udp port mangle operationRoi Dayan1-2/+2
Need to use the udp header type and not tcp. Fixes: 9c26ba9b1f45 ("net/sched: act_ct: Instantiate flow table entry actions") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Link: https://lore.kernel.org/r/20201019090244.3015186-1-roid@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20netsec: ignore 'phy-mode' device property on ACPI systemsArd Biesheuvel2-8/+20
Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20bpf, doc: Fix patchwork URL to point to kernel.org instanceDaniel Borkmann1-1/+2
Follow-up on ebb034b15bfa ("bpf: Migrate from patchwork.ozlabs.org to patchwork.kernel.org.") in order to fix up the patchwork URL (Q) in the MAINTAINERS file for BPF subsystem. While at it, also add the official website (W) entry. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/f73ae01c7e6f9cf0a3890f2ca988a8e69190c50b.1603223852.git.daniel@iogearbox.net
2020-10-20nfc: remove unneeded breakTom Rix2-2/+0
A break is not needed if it is preceded by a return Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201019191500.9264-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20net: remove unneeded breakTom Rix4-7/+0
A break is not needed if it is preceded by a return or goto Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201019172607.31622-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-20netfilter: nftables_offload: KASAN slab-out-of-bounds Read in ↵Saeed Mirzamohammadi3-5/+11
nft_flow_rule_create This patch fixes the issue due to: BUG: KASAN: slab-out-of-bounds in nft_flow_rule_create+0x622/0x6a2 net/netfilter/nf_tables_offload.c:40 Read of size 8 at addr ffff888103910b58 by task syz-executor227/16244 The error happens when expr->ops is accessed early on before performing the boundary check and after nft_expr_next() moves the expr to go out-of-bounds. This patch checks the boundary condition before expr->ops that fixes the slab-out-of-bounds Read issue. Add nft_expr_more() and use it to fix this problem. Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-20docs: nf_flowtable: fix typo.Jeremy Sowden1-1/+1
"mailined" should be "mainlined." Signed-off-by: Jeremy Sowden <jeremy@azazel.net> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-20netfilter: ebtables: Fixes dropping of small packets in bridge natTimothée COCAULT3-3/+3
Fixes an error causing small packets to get dropped. skb_ensure_writable expects the second parameter to be a length in the ethernet payload.=20 If we want to write the ethernet header (src, dst), we should pass 0. Otherwise, packets with small payloads (< ETH_ALEN) will get dropped. Fixes: c1a831167901 ("netfilter: bridge: convert skb_make_writable to skb_ensure_writable") Signed-off-by: Timothée COCAULT <timothee.cocault@orange.com> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-20netfilter: Drop fragmented ndisc packets assembled in netfilterGeorg Kohmann1-0/+1
Fragmented ndisc packets assembled in netfilter not dropped as specified in RFC 6980, section 5. This behaviour breaks TAHI IPv6 Core Conformance Tests v6LC.2.1.22/23, V6LC.2.2.26/27 and V6LC.2.3.18. Setting IP6SKB_FRAGMENTED flag during reassembly. References: commit b800c3b966bc ("ipv6: drop fragmented ndisc packets by default (RFC 6980)") Signed-off-by: Georg Kohmann <geokohma@cisco.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-20netfilter: conntrack: connection timeout after re-registerFrancesco Ruggeri1-6/+13
If the first packet conntrack sees after a re-register is an outgoing keepalive packet with no data (SEG.SEQ = SND.NXT-1), td_end is set to SND.NXT-1. When the peer correctly acknowledges SND.NXT, tcp_in_window fails check III (Upper bound for valid (s)ack: sack <= receiver.td_end) and returns false, which cascades into nf_conntrack_in setting skb->_nfct = 0 and in later conntrack iptables rules not matching. In cases where iptables are dropping packets that do not match conntrack rules this can result in idle tcp connections to time out. v2: adjust td_end when getting the reply rather than when sending out the keepalive packet. Fixes: f94e63801ab2 ("netfilter: conntrack: reset tcp maxwin on re-register") Signed-off-by: Francesco Ruggeri <fruggeri@arista.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-20ipvs: adjust the debug info in function set_tcp_statelongguang.yue1-4/+6
Outputting client,virtual,dst addresses info when tcp state changes, which makes the connection debug more clear Signed-off-by: longguang.yue <bigclouds@163.com> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-10-19nexthop: Fix performance regression in nexthop deletionIdo Schimmel1-1/+1
While insertion of 16k nexthops all using the same netdev ('dummy10') takes less than a second, deletion takes about 130 seconds: # time -p ip -b nexthop.batch real 0.29 user 0.01 sys 0.15 # time -p ip link set dev dummy10 down real 131.03 user 0.06 sys 0.52 This is because of repeated calls to synchronize_rcu() whenever a nexthop is removed from a nexthop group: # /usr/share/bcc/tools/offcputime -p `pgrep -nx ip` -K ... b'finish_task_switch' b'schedule' b'schedule_timeout' b'wait_for_completion' b'__wait_rcu_gp' b'synchronize_rcu.part.0' b'synchronize_rcu' b'__remove_nexthop' b'remove_nexthop' b'nexthop_flush_dev' b'nh_netdev_event' b'raw_notifier_call_chain' b'call_netdevice_notifiers_info' b'__dev_notify_flags' b'dev_change_flags' b'do_setlink' b'__rtnl_newlink' b'rtnl_newlink' b'rtnetlink_rcv_msg' b'netlink_rcv_skb' b'rtnetlink_rcv' b'netlink_unicast' b'netlink_sendmsg' b'____sys_sendmsg' b'___sys_sendmsg' b'__sys_sendmsg' b'__x64_sys_sendmsg' b'do_syscall_64' b'entry_SYSCALL_64_after_hwframe' - ip (277) 126554955 Since nexthops are always deleted under RTNL, synchronize_net() can be used instead. It will call synchronize_rcu_expedited() which only blocks for several microseconds as opposed to multiple milliseconds like synchronize_rcu(). With this patch deletion of 16k nexthops takes less than a second: # time -p ip link set dev dummy10 down real 0.12 user 0.00 sys 0.04 Tested with fib_nexthops.sh which includes torture tests that prompted the initial change: # ./fib_nexthops.sh ... Tests passed: 134 Tests failed: 0 Fixes: 90f33bffa382 ("nexthops: don't modify published nexthop groups") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by: David Ahern <dsahern@gmail.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Link: https://lore.kernel.org/r/20201016172914.643282-1-idosch@idosch.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-19net: dsa: seville: the packet buffer is 2 megabits, not megabytesMaxim Kochetkov1-1/+1
The VSC9953 Seville switch has 2 megabits of buffer split into 4360 words of 60 bytes each. 2048 * 1024 is 2 megabytes instead of 2 megabits. 2 megabits is (2048 / 8) * 1024 = 256 * 1024. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Fixes: a63ed92d217f ("net: dsa: seville: fix buffer size of the queue system") Link: https://lore.kernel.org/r/20201019050625.21533-1-fido_max@inbox.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-19selftests: rtnetlink: load fou module for kci_test_encap_fou() testPo-Hsu Lin2-0/+6
The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh needs the fou module to work. Otherwise it will fail with: $ ip netns exec "$testns" ip fou add port 7777 ipproto 47 RTNETLINK answers: No such file or directory Error talking to the kernel Add the CONFIG_NET_FOU into the config file as well. Which needs at least to be set as a loadable module. Fixes: 6227efc1a20b ("selftests: rtnetlink.sh: add vxlan and fou test cases") Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Link: https://lore.kernel.org/r/20201019030928.9859-1-po-hsu.lin@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-19net: dsa: tag_ksz: KSZ8795 and KSZ9477 also use tail tagsChristian Eggers1-0/+2
The Marvell 88E6060 uses tag_trailer.c and the KSZ8795, KSZ9477 and KSZ9893 switches also use tail tags. Fixes: 7a6ffe764be3 ("net: dsa: point out the tail taggers") Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201016171603.10587-1-ceggers@arri.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-19net: korina: cast KSEG0 address to pointer in kfreeValentin Vidic1-2/+2
Fixes gcc warning: passing argument 1 of 'kfree' makes pointer from integer without a cast Fixes: 3af5f0f5c74e ("net: korina: fix kfree of rx/tx descriptor array") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr> Link: https://lore.kernel.org/r/20201018184255.28989-1-vvidic@valentin-vidic.from.hr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-19r8169: fix operation under forced interrupt threadingHeiner Kallweit1-4/+4
For several network drivers it was reported that using __napi_schedule_irqoff() is unsafe with forced threading. One way to fix this is switching back to __napi_schedule, but then we lose the benefit of the irqoff version in general. As stated by Eric it doesn't make sense to make the minimal hard irq handlers in drivers using NAPI a thread. Therefore ensure that the hard irq handler is never thread-ified. Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff") Link: https://lkml.org/lkml/2020/10/18/19 Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/4d3ef84a-c812-5072-918a-22a6f6468310@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-03 04:50:49 +0000