- 31 Jul, 2023 3 commits
-
-
Martin KaFai Lau authored
Hou Tao says: ==================== The patchset fixes two reported warning in cpu-map when running xdp_redirect_cpu and some RT threads concurrently. Patch #1 fixes the warning in __cpu_map_ring_cleanup() when kthread is stopped prematurely. Patch #2 fixes the warning in __xdp_return() when there are pending skbs in ptr_ring. Please see individual patches for more details. And comments are always welcome. ==================== Signed-off-by:Martin KaFai Lau <martin.lau@kernel.org>
-
Hou Tao authored
The following warning was reported when running xdp_redirect_cpu with both skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150 __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The reason for the warning is twofold. One is due to the kthread cpu_map_kthread_run() is stopped prematurely. Another one is __cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be fixed by the preceding patch and ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But as the comments in __cpu_map_ring_cleanup() said, handling and freeing skbs in ptr_ring as well to "catch any broken behaviour gracefully". Fixes: 11941f8a ("bpf: cpumap: Implement generic cpumap") Signed-off-by:
Hou Tao <houtao1@huawei.com> Acked-by:
Jesper Dangaard Brouer <hawk@kernel.org> Link: https://lore.kernel.org/r/20230729095107.1722450-3-houtao@huaweicloud.comSigned-off-by:
-
Hou Tao authored
The following warning was reported when running stress-mode enabled xdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The root cause is the same as commit 43690164 ("bpf: cpumap: Fix memory leak in cpu_map_update_elem"). The kthread is stopped prematurely by kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call cpu_map_kthread_run() at all but XDP program has already queued some frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks the ptr_ring, it will find it was not emptied and report a warning. An alternative fix is to use __cpu_map_ring_cleanup() to drop these pending frames or skbs when kthread_stop() returns -EINTR, but it may confuse the user, because these frames or skbs have been handled correctly by XDP program. So instead of dropping these frames or skbs, just make sure the per-cpu kthread is running before __cpu_map_entry_alloc() returns. After apply the fix, the error handle for kthread_stop() will be unnecessary because it will always return 0, so just remove it. Fixes: 6710e112 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP") Signed-off-by:
Pu Lehui <pulehui@huawei.com> Acked-by:
-
- 27 Jul, 2023 1 commit
-
-
Lin Ma authored
The nla_for_each_nested parsing in function bpf_sk_storage_diag_alloc does not check the length of the nested attribute. This can lead to an out-of-attribute read and allow a malformed nlattr (e.g., length 0) to be viewed as a 4 byte integer. This patch adds an additional check when the nlattr is getting counted. This makes sure the latter nla_get_u32 can access the attributes with the correct length. Fixes: 1ed4d924 ("bpf: INET_DIAG support in bpf_sk_storage") Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Lin Ma <linma@zju.edu.cn> Reviewed-by:
-
- 26 Jul, 2023 3 commits
-
-
Alexei Starovoitov authored
Jiri Olsa says: ==================== bpf: Disable preemption in perf_event_output helpers code hi, we got report of kernel crash [1][3] within bpf_event_output helper. The reason is the nesting protection code in bpf_event_output that expects disabled preemption, which is not guaranteed for programs executed by bpf_prog_run_array_cg. I managed to reproduce on tracing side where we have the same problem in bpf_perf_event_output. The reproducer [2] just creates busy uprobe and call bpf_perf_event_output helper a lot. v3 changes: - added acks and fixed 'Fixes' tag style [Hou Tao] - added Closes tag to patch 2 v2 changes: - I changed 'Fixes' commits to where I saw we switched from preempt_disable to migrate_disable, but I'm not completely sure about the patch 2, because it was tricky to find, would be nice if somebody could check on that thanks, jirka [1] https://github.com/cilium/cilium/issues/26756 [2] https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/commit/?h=bpf_output_fix_reproducer&id=8054dcc634121b884c7c331329d61d93351d03b5 [3] slack: [66194.378161] BUG: kernel NULL pointer dereference, address: 0000000000000001 [66194.378324] #PF: supervisor instruction fetch in kernel mode [66194.378447] #PF: error_code(0x0010) - not-present page ... [66194.378692] Oops: 0010 [#1] PREEMPT SMP NOPTI ... [66194.380666] <TASK> [66194.380775] ? perf_output_sample+0x12a/0x9a0 [66194.380902] ? finish_task_switch.isra.0+0x81/0x280 [66194.381024] ? perf_event_output+0x66/0xa0 [66194.381148] ? bpf_event_output+0x13a/0x190 [66194.381270] ? bpf_event_output_data+0x22/0x40 [66194.381391] ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb [66194.381519] ? xa_load+0x87/0xe0 [66194.381635] ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0 [66194.381759] ? release_sock+0x3e/0x90 [66194.381876] ? sk_setsockopt+0x1a1/0x12f0 [66194.381996] ? udp_pre_connect+0x36/0x50 [66194.382114] ? inet_dgram_connect+0x93/0xa0 [66194.382233] ? __sys_connect+0xb4/0xe0 [66194.382353] ? udp_setsockopt+0x27/0x40 [66194.382470] ? __pfx_udp_push_pending_frames+0x10/0x10 [66194.382593] ? __sys_setsockopt+0xdf/0x1a0 [66194.382713] ? __x64_sys_connect+0xf/0x20 [66194.382832] ? do_syscall_64+0x3a/0x90 [66194.382949] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [66194.383077] </TASK> --- ==================== Link: https://lore.kernel.org/r/20230725084206.580930-1-jolsa@kernel.orgSigned-off-by:Alexei Starovoitov <ast@kernel.org>
-
Jiri Olsa authored
We received report [1] of kernel crash, which is caused by using nesting protection without disabled preemption. The bpf_event_output can be called by programs executed by bpf_prog_run_array_cg function that disabled migration but keeps preemption enabled. This can cause task to be preempted by another one inside the nesting protection and lead eventually to two tasks using same perf_sample_data buffer and cause crashes like: BUG: kernel NULL pointer dereference, address: 0000000000000001 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page ... ? perf_output_sample+0x12a/0x9a0 ? finish_task_switch.isra.0+0x81/0x280 ? perf_event_output+0x66/0xa0 ? bpf_event_output+0x13a/0x190 ? bpf_event_output_data+0x22/0x40 ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb ? xa_load+0x87/0xe0 ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0 ? release_sock+0x3e/0x90 ? sk_setsockopt+0x1a1/0x12f0 ? udp_pre_connect+0x36/0x50 ? inet_dgram_connect+0x93/0xa0 ? __sys_connect+0xb4/0xe0 ? udp_setsockopt+0x27/0x40 ? __pfx_udp_push_pending_frames+0x10/0x10 ? __sys_setsockopt+0xdf/0x1a0 ? __x64_sys_connect+0xf/0x20 ? do_syscall_64+0x3a/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc Fixing this by disabling preemption in bpf_event_output. [1] https://github.com/cilium/cilium/issues/26756 Cc: stable@vger.kernel.org Reported-by:
Oleg "livelace" Popov <o.popov@livelace.ru> Closes: https://github.com/cilium/cilium/issues/26756 Fixes: 2a916f2f ("bpf: Use migrate_disable/enable in array macros and cgroup/lirc code.") Acked-by:
Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20230725084206.580930-3-jolsa@kernel.orgSigned-off-by:
-
Jiri Olsa authored
The nesting protection in bpf_perf_event_output relies on disabled preemption, which is guaranteed for kprobes and tracepoints. However bpf_perf_event_output can be also called from uprobes context through bpf_prog_run_array_sleepable function which disables migration, but keeps preemption enabled. This can cause task to be preempted by another one inside the nesting protection and lead eventually to two tasks using same perf_sample_data buffer and cause crashes like: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffffff82be3eea ... Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x176/0x4d0 ? exc_page_fault+0x132/0x230 ? asm_exc_page_fault+0x22/0x30 ? perf_output_sample+0x12b/0x910 ? perf_event_output+0xd0/0x1d0 ? bpf_perf_event_output+0x162/0x1d0 ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87 ? __uprobe_perf_func+0x12b/0x540 ? uprobe_dispatcher+0x2c4/0x430 ? uprobe_notify_resume+0x2da/0xce0 ? atomic_notifier_call_chain+0x7b/0x110 ? exit_to_user_mode_prepare+0x13e/0x290 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_exc_int3+0x35/0x40 Fixing this by disabling preemption in bpf_perf_event_output. Cc: stable@vger.kernel.org Fixes: 8c7dcb84 ("bpf: implement sleepable uprobes by chaining gps") Acked-by:
-
- 25 Jul, 2023 8 commits
-
-
Vincent Whitchurch authored
commit a3a57bf0 ("net: stmmac: work around sporadic tx issue on link-up") worked around a problem with TX sometimes not working after a link-up by avoiding a redundant write to MAC_CTRL_REG (aka GMAC_CONFIG), since the IP appeared to have problems with handling multiple writes to that register in some cases. That commit however only added the work around to dwmac_lib.c (apart from the common code in stmmac_main.c), but my systems with version 4.21a of the IP exhibit the same problem, so add the work around to dwmac4_lib.c too. Fixes: a3a57bf0 ("net: stmmac: work around sporadic tx issue on link-up") Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721-stmmac-tx-workaround-v1-1-9411cbd5ee07@axis.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Suman Ghosh authored
As of today, hash extraction support is enabled for all the silicons. Because of which we are facing initialization issues when the silicon does not support hash extraction. During creation of the hardware parsing table for IPv6 address, we need to consider if hash extraction is enabled then extract only 32 bit, otherwise 128 bit needs to be extracted. This patch fixes the issue and configures the hardware parser based on the availability of the feature. Fixes: a95ab935 ("octeontx2-af: Use hashed field in MCAM key") Signed-off-by:
Suman Ghosh <sumang@marvell.com> Reviewed-by:
-
Paolo Abeni authored
Hangbin Liu says: ==================== Fix up dev flags when add P2P down link When adding p2p interfaces to bond/team. The POINTOPOINT, NOARP flags are not inherit to up devices. Which will trigger IPv6 DAD. Since there is no ethernet MAC address for P2P devices. This will cause unexpected DAD failures. ==================== Link: https://lore.kernel.org/r/20230721040356.3591174-1-liuhangbin@gmail.comSigned-off-by:
-
Hangbin Liu authored
When adding a point to point downlink to team device, we neglected to reset the team's flags, which were still using flags like BROADCAST and MULTICAST. Consequently, this would initiate ARP/DAD for P2P downlink interfaces, such as when adding a GRE device to team device. Fix this by remove multicast/broadcast flags and add p2p and noarp flags. After removing the none ethernet interface and adding an ethernet interface to team, we need to reset team interface flags. Unlike bonding interface, team do not need restore IFF_MASTER, IFF_SLAVE flags. Reported-by:
Liang Li <liali@redhat.com> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2221438 Fixes: 1d76efe1 ("team: add support for non-ethernet devices") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
-
Hangbin Liu authored
When adding a point to point downlink to the bond, we neglected to reset the bond's flags, which were still using flags like BROADCAST and MULTICAST. Consequently, this would initiate ARP/DAD for P2P downlink interfaces, such as when adding a GRE device to the bonding. To address this issue, let's reset the bond's flags for P2P interfaces. Before fix: 7: gre0@NONE: <POINTOPOINT,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond0 state UNKNOWN group default qlen 1000 link/gre6 2006:70:10::1 peer 2006:70:10::2 permaddr 167f:18:f188:: 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/gre6 2006:70:10::1 brd 2006:70:10::2 inet6 fe80::200:ff:fe00:0/64 scope link valid_lft forever preferred_lft forever After fix: 7: gre0@NONE: <POINTOPOINT,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond2 state UNKNOWN group default qlen 1000 link/gre6 2006:70:10::1 peer 2006:70:10::2 permaddr c29e:557a:e9d9:: 8: bond0: <POINTOPOINT,NOARP,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/gre6 2006:70:10::1 peer 2006:70:10::2 inet6 fe80::1/64 scope link valid_lft forever preferred_lft forever Reported-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-07-21 (i40e, iavf) This series contains updates to i40e and iavf drivers. Wang Ming corrects an error check on i40e. Jake unlocks crit_lock on allocation failure to prevent deadlock and stops re-enabling of interrupts when it's not intended for iavf. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: iavf: check for removal state before IAVF_FLAG_PF_COMMS_FAILED iavf: fix potential deadlock on allocation failure i40e: Fix an NULL vs IS_ERR() bug for debugfs_create_dir() ==================== Link: https://lore.kernel.org/r/20230721155812.1292752-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-6.5-20230724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2023-07-24 The first patch is by me and adds a missing set of CAN state to CAN_STATE_STOPPED on close in the gs_usb driver. The last patch is by Eric Dumazet and fixes a lockdep issue in the CAN raw protocol. * tag 'linux-can-fixes-for-6.5-20230724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: raw: fix lockdep issue in raw_release() can: gs_usb: gs_can_close(): add missing set of CAN state to CAN_STATE_STOPPED ==================== Link: https://lore.kernel.org/r/20230724150141.766047-1-mkl@pengutronix.deSigned-off-by:
-
Jedrzej Jagielski authored
Fix ethtool FDIR logic to not use memory after its release. In the ice_ethtool_fdir.c file there are 2 spots where code can refer to pointers which may be missing. In the ice_cfg_fdir_xtrct_seq() function seg may be freed but even then may be still used by memcpy(&tun_seg[1], seg, sizeof(*seg)). In the ice_add_fdir_ethtool() function struct ice_fdir_fltr *input may first fail to be added via ice_fdir_update_list_entry() but then may be deleted by ice_fdir_update_list_entry. Terminate in both cases when the returned value of the previous operation is other than 0, free memory and don't use it anymore. Reported-by:
Michal Schmidt <mschmidt@redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2208423 Fixes: cac2a27c ("ice: Support IPv4 Flow Director filters") Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by:
Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20230721155854.1292805-1-anthony.l.nguyen@intel.comSigned-off-by:
-
- 24 Jul, 2023 15 commits
-
-
Stewart Smith authored
For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6 ("ipv6: use a stronger hash for tcp") Signed-off-by:
Stewart Smith <trawets@amazon.com> Signed-off-by:
Samuel Mendoza-Jonas <samjonas@amazon.com> Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
-
Wei Fang authored
According to the implementation of XDP of FEC driver, the XDP path shares the transmit queues with the kernel network stack, so it is possible to lead to a tx timeout event when XDP uses the tx queue pretty much exclusively. And this event will cause the reset of the FEC hardware. To avoid timeout in this case, we use the txq_trans_cond_update() interface to update txq->trans_start to jiffies so that watchdog won't generate a transmit timeout warning. Fixes: 6d6b39f1 ("net: fec: add initial XDP support") Signed-off-by:
Wei Fang <wei.fang@nxp.com> Link: https://lore.kernel.org/r/20230721083559.2857312-1-wei.fang@nxp.comSigned-off-by:
-
Maciej Żenczykowski authored
currently on 6.4 net/main: # ip link add dummy1 type dummy # echo 1 > /proc/sys/net/ipv6/conf/dummy1/use_tempaddr # ip link set dummy1 up # ip -6 addr add 2000::1/64 mngtmpaddr dev dummy1 # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::44f3:581c:8ca:3983/64 scope global temporary dynamic valid_lft 604800sec preferred_lft 86172sec inet6 2000::1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever # ip -6 addr del 2000::44f3:581c:8ca:3983/64 dev dummy1 (can wait a few seconds if you want to, the above delete isn't [directly] the problem) # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever # ip -6 addr del 2000::1/64 mngtmpaddr dev dummy1 # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::81c9:56b7:f51a:b98f/64 scope global temporary dynamic valid_lft 604797sec preferred_lft 86169sec inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever This patch prevents this new 'global temporary dynamic' address from being created by the deletion of the related (same subnet prefix) 'mngtmpaddr' (which is triggered by there already being no temporary addresses). Cc: Jiri Pirko <jiri@resnulli.us> Fixes: 53bd6749 ("ipv6 addrconf: introduce IFA_F_MANAGETEMPADDR to tell kernel to manage temporary addresses") Reported-by:Xiao Ma <xiaom@google.com> Signed-off-by:
Maciej Żenczykowski <maze@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230720160022.1887942-1-maze@google.comSigned-off-by:
-
Yuanjun Gong authored
in atl1e_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Fixes: a6a53252 ("atl1e: Atheros L1E Gigabit Ethernet driver") Signed-off-by:
Yuanjun Gong <ruc_gongyuanjun@163.com> Reviewed-by:
-
Yuanjun Gong authored
in atl1_tso(), it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Fixes: 401c0aab ("atl1: simplify tx packet descriptor") Signed-off-by:
-
David S. Miller authored
Jiri Benc says: ==================== vxlan: fix GRO with VXLAN-GPE The first patch generalizes code for the second patch, which is a fix for broken VXLAN-GPE GRO. Thanks to Paolo for noticing the bug. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Jiri Benc authored
In VXLAN-GPE, there may not be an Ethernet header following the VXLAN header. But in GRO, the vxlan driver calls eth_gro_receive unconditionally, which means the following header is incorrectly parsed as Ethernet. Introduce GPE specific GRO handling. For better performance, do not check for GPE during GRO but rather install a different set of functions at setup time. Fixes: e1e5314d ("vxlan: implement GPE") Reported-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
Jiri Benc authored
The vxlan_parse_gpe_hdr function extracts the next protocol value from the GPE header and marks GPE bits as parsed. In order to be used in the next patch, split the function into protocol extraction and bit marking. The bit marking is meaningful only in vxlan_rcv; move it directly there. Rename the function to vxlan_parse_gpe_proto to reflect what it now does. Remove unused arguments skb and vxflags. Move the function earlier in the file to allow it to be called from more places in the next patch. Signed-off-by:
-
Yuanjun Gong authored
in atl1c_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Signed-off-by:
-
Jiri Benc authored
VXLAN-GPE does not add an extra inner Ethernet header. Take that into account when calculating header length. This causes problems in skb_tunnel_check_pmtu, where incorrect PMTU is cached. In the collect_md mode (which is the only mode that VXLAN-GPE supports), there's no magic auto-setting of the tunnel interface MTU. It can't be, since the destination and thus the underlying interface may be different for each packet. So, the administrator is responsible for setting the correct tunnel interface MTU. Apparently, the administrators are capable enough to calculate that the maximum MTU for VXLAN-GPE is (their_lower_MTU - 36). They set the tunnel interface MTU to 1464. If you run a TCP stream over such interface, it's then segmented according to the MTU 1464, i.e. producing 1514 bytes frames. Which is okay, this still fits the lower MTU. However, skb_tunnel_check_pmtu (called from vxlan_xmit_one) uses 50 as the header size and thus incorrectly calculates the frame size to be 1528. This leads to ICMP too big message being generated (locally), PMTU of 1450 to be cached and the TCP stream to be resegmented. The fix is to use the correct actual header size, especially for skb_tunnel_check_pmtu calculation. Fixes: e1e5314d ("vxlan: implement GPE") Signed-off-by:
-
David S. Miller authored
Jijie Shao says: ==================== There are some bugfix for the HNS3 ethernet driver There are some bugfix for the HNS3 ethernet driver ==================== Reviewed-by:
-
Jijie Shao authored
In dwrr mode, the default bandwidth weight of disabled tc is set to 0. If the bandwidth weight is 0, the mode will change to sp. Therefore, disabled tc default bandwidth weight need changed to 1, and 0 is returned when query the bandwidth weight of disabled tc. In addition, driver need stop configure bandwidth weight if tc is disabled. Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Signed-off-by:
-
Jijie Shao authored
Currently, the weight saved by the driver is used as the query result, which may be different from the actual weight in the register. Therefore, the register value read from the firmware is used as the query result Fixes: 0e32038d ("net: hns3: refactor dump tc of debugfs") Signed-off-by:
-
Hao Lan authored
When the tm module is configured with traffic, traffic may be abnormal. This patch fixes this problem. Before the tm module is configured, traffic processing should be stopped. After the tm module is configured, traffic processing is enabled. Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Hao Lan authored
Current only the first 32 bits of the capability flag bit are considered. When the matching capability flag bit is greater than 31 bits, it will get an error bit.This patch use bitmap to solve this issue. It can handle each capability bit whitout bit width limit. Fixes: da77aef9 ("net: hns3: create common cmdq resource allocate/free/query APIs") Signed-off-by:
-
- 23 Jul, 2023 1 commit
-
-
Jiawen Wu authored
Clear MV_V2_PORT_CTRL_PWRDOWN bit to set power up for 88x3310 PHY, it sometimes does not take effect immediately. And a read of this register causes the bit not to clear. This will cause mv3310_reset() to time out, which will fail the config initialization. So add a delay before the next access. Fixes: c9cc1c81 ("net: phy: marvell10g: place in powersave mode at probe") Signed-off-by:
Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
- 22 Jul, 2023 1 commit
-
-
Jakub Kicinski authored
page pool and XDP should not be accessed from IRQ context which may happen if drivers try to clean up XDP TX with NAPI budget of 0. Link: https://lore.kernel.org/r/20230720161323.2025379-1-kuba@kernel.orgSigned-off-by:
-
- 21 Jul, 2023 3 commits
-
-
Jacob Keller authored
In iavf_adminq_task(), if the function can't acquire the adapter->crit_lock, it checks if the driver is removing. If so, it simply exits without re-enabling the interrupt. This is done to ensure that the task stops processing as soon as possible once the driver is being removed. However, if the IAVF_FLAG_PF_COMMS_FAILED is set, the function checks this before attempting to acquire the lock. In this case, the function exits early and re-enables the interrupt. This will happen even if the driver is already removing. Avoid this, by moving the check to after the adapter->crit_lock is acquired. This way, if the driver is removing, we will not re-enable the interrupt. Fixes: fc2e6b3b ("iavf: Rework mutexes for better synchronisation") Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by:
-
Jacob Keller authored
In iavf_adminq_task(), if kzalloc() fails to allocate the event.msg_buf, the function will exit without releasing the adapter->crit_lock. This is unlikely, but if it happens, the next access to that mutex will deadlock. Fix this by moving the unlock to the end of the function, and adding a new label to allow jumping to the unlock portion of the function exit flow. Fixes: fc2e6b3b ("iavf: Rework mutexes for better synchronisation") Signed-off-by:
-
Wang Ming authored
The debugfs_create_dir() function returns error pointers. It never returns NULL. Most incorrect error checks were fixed, but the one in i40e_dbg_init() was forgotten. Fix the remaining error check. Fixes: 02e9c290 ("i40e: debugfs interface") Signed-off-by:
Wang Ming <machel@vivo.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
- 20 Jul, 2023 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from BPF, netfilter, bluetooth and CAN. Current release - regressions: - eth: r8169: multiple fixes for PCIe ASPM-related problems - vrf: fix RCU lockdep splat in output path Previous releases - regressions: - gso: fall back to SW segmenting with GSO_UDP_L4 dodgy bit set - dsa: mv88e6xxx: do a final check before timing out when polling - nf_tables: fix sleep in atomic in nft_chain_validate Previous releases - always broken: - sched: fix undoing tcf_bind_filter() in multiple classifiers - bpf, arm64: fix BTI type used for freplace attached functions - can: gs_usb: fix time stamp counter initialization - nft_set_pipapo: fix improper element removal (leading to UAF) Misc: - net: support STP on bridge in non-root netns, STP prevents packet loops so not supporting it results in freezing systems of unsuspecting users, and in turn very upset noises being made - fix kdoc warnings - annotate various bits of TCP state to prevent data races" * tag 'net-6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (95 commits) net: phy: prevent stale pointer dereference in phy_init() tcp: annotate data-races around fastopenq.max_qlen tcp: annotate data-races around icsk->icsk_user_timeout tcp: annotate data-races around tp->notsent_lowat tcp: annotate data-races around rskq_defer_accept tcp: annotate data-races around tp->linger2 tcp: annotate data-races around icsk->icsk_syn_retries tcp: annotate data-races around tp->keepalive_probes tcp: annotate data-races around tp->keepalive_intvl tcp: annotate data-races around tp->keepalive_time tcp: annotate data-races around tp->tsoffset tcp: annotate data-races around tp->tcp_tx_delay Bluetooth: MGMT: Use correct address for memcpy() Bluetooth: btusb: Fix bluetooth on Intel Macbook 2014 Bluetooth: SCO: fix sco_conn related locking and validity issues Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor() Bluetooth: coredump: fix building with coredump disabled Bluetooth: ISO: fix iso_conn related locking and validity issues Bluetooth: hci_event: call disconnect callback before deleting conn ... -
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetoothJakub Kicinski authored
Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix building with coredump disabled - Fix use-after-free in hci_remove_adv_monitor - Use RCU for hci_conn_params and iterate safely in hci_sync - Fix locking issues on ISO and SCO - Fix bluetooth on Intel Macbook 2014 * tag 'for-net-2023-07-20' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: MGMT: Use correct address for memcpy() Bluetooth: btusb: Fix bluetooth on Intel Macbook 2014 Bluetooth: SCO: fix sco_conn related locking and validity issues Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor() Bluetooth: coredump: fix building with coredump disabled Bluetooth: ISO: fix iso_conn related locking and validity issues Bluetooth: hci_event: call disconnect callback before deleting conn Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync ==================== Link: https://lore.kernel.org/r/20230720190201.446469-1-luiz.dentz@gmail.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski authored
Florian Westphal says: ==================== Netfilter fixes for net: The following patchset contains Netfilter fixes for net: 1. Fix spurious -EEXIST error from userspace due to padding holes, this was broken since 4.9 days when 'ignore duplicate entries on insert' feature was added. 2. Fix a sched-while-atomic bug, present since 5.19. 3. Properly remove elements if they lack an "end range". nft userspace always sets an end range attribute, even when its the same as the start, but the abi doesn't have such a restriction. Always broken since it was added in 5.6, all three from myself. 4 + 5: Bound chain needs to be skipped in netns release and on rule flush paths, from Pablo Neira. * tag 'nf-23-07-20' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: skip bound chain on rule flush netfilter: nf_tables: skip bound chain in netns release path netfilter: nft_set_pipapo: fix improper element removal netfilter: nf_tables: can't schedule in nft_chain_validate netfilter: nf_tables: fix spurious set element insertion failure ==================== Link: https://lore.kernel.org/r/20230720165143.30208-1-fw@strlen.deSigned-off-by:
-
Vladimir Oltean authored
mdio_bus_init() and phy_driver_register() both have error paths, and if those are ever hit, ethtool will have a stale pointer to the phy_ethtool_phy_ops stub structure, which references memory from a module that failed to load (phylib). It is probably hard to force an error in this code path even manually, but the error teardown path of phy_init() should be the same as phy_exit(), which is now simply not the case. Fixes: 55d8f053 ("net: phy: Register ethtool PHY operations") Link: https://lore.kernel.org/netdev/ZLaiJ4G6TaJYGJyU@shell.armlinux.org.uk/Suggested-by:
Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230720000231.1939689-1-vladimir.oltean@nxp.comSigned-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== tcp: add missing annotations This series was inspired by one syzbot (KCSAN) report. do_tcp_getsockopt() does not lock the socket, we need to annotate most of the reads there (and other places as well). This is a first round, another series will come later. ==================== Link: https://lore.kernel.org/r/20230719212857.3943972-1-edumazet@google.comSigned-off-by:
-
