- 14 Sep, 2023 17 commits
-
-
Eric Dumazet authored
udp->pcflag, udp->pcslen and udp->pcrlen reads/writes are racy. Move udp->pcflag to udp->udp_flags for atomicity, and add READ_ONCE()/WRITE_ONCE() annotations for pcslen and pcrlen. Fixes: ba4e58ec ("[NET]: Supporting UDP-Lite (RFC 3828) in Linux") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Eric Dumazet authored
This flag is set but never read, we can remove it. Signed-off-by:
-
Eric Dumazet authored
syzbot/KCSAN complained about UDP_ENCAP_L2TPINUDP setsockopt() racing. Add READ_ONCE()/WRITE_ONCE() to document races on this lockless field. syzbot report was: BUG: KCSAN: data-race in udp_lib_setsockopt / udp_lib_setsockopt read-write to 0xffff8881083603fa of 1 bytes by task 16557 on cpu 0: udp_lib_setsockopt+0x682/0x6c0 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2779 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697 __sys_setsockopt+0x1c9/0x230 net/socket.c:2263 __do_sys_setsockopt net/socket.c:2274 [inline] __se_sys_setsockopt net/socket.c:2271 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read-write to 0xffff8881083603fa of 1 bytes by task 16554 on cpu 1: udp_lib_setsockopt+0x682/0x6c0 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2779 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697 __sys_setsockopt+0x1c9/0x230 net/socket.c:2263 __do_sys_setsockopt net/socket.c:2274 [inline] __se_sys_setsockopt net/socket.c:2271 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x05 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 16554 Comm: syz-executor.5 Not tainted 6.5.0-rc7-syzkaller-00004-gf7757129 #0 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Eric Dumazet authored
Move udp->encap_enabled to udp->udp_flags. Add udp_test_and_set_bit() helper to allow lockless udp_tunnel_encap_enable() implementation. Signed-off-by:
-
Eric Dumazet authored
These are read locklessly, move them to udp_flags to fix data-races. Signed-off-by:
-
Eric Dumazet authored
UDP_ENCAP_ESPINUDP_NON_IKE setsockopt() writes over up->encap_rcv while other cpus read it. Fixes: 067b207b ("[UDP]: Cleanup UDP encapsulation code") Signed-off-by:
-
Eric Dumazet authored
syzbot reported that udp->gro_enabled can be read locklessly. Use one atomic bit from udp->udp_flags. Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.") Reported-by:
-
Eric Dumazet authored
syzbot reported that udp->no_check6_rx can be read locklessly. Use one atomic bit from udp->udp_flags. Fixes: 1c19448c ("net: Make enabling of zero UDP6 csums more restrictive") Reported-by:
-
Eric Dumazet authored
syzbot reported that udp->no_check6_tx can be read locklessly. Use one atomic bit from udp->udp_flags Fixes: 1c19448c ("net: Make enabling of zero UDP6 csums more restrictive") Reported-by:
-
Eric Dumazet authored
According to syzbot, it is time to use proper atomic flags for various UDP flags. Add udp_flags field, and convert udp->corkflag to first bit in it. Signed-off-by:
-
Lorenzo Bianconi authored
Check if update_wo_rx_stats function pointer is properly set in mtk_wed_update_rx_stats routine before accessing it. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/b0d233386e059bccb59f18f69afb79a7806e5ded.1694507226.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Similar to ethernet ports, rely on mtk_pse_port definitions for pse wdma ports as well. Signed-off-by:
-
Jiawen Wu authored
Move similar code of accessing MDIO bus from txgbe/ngbe to libwx. Signed-off-by:
Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by:
-
Sieng-Piaw Liew authored
This is based on alx driver commit 881d0327 ("net: alx: Work around the DMA RX overflow issue"). The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester. Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address. Tested on AR8131 on Acer 4540. Signed-off-by:
Sieng-Piaw Liew <liew.s.piaw@gmail.com> Link: https://lore.kernel.org/r/20230912010711.12036-1-liew.s.piaw@gmail.comSigned-off-by:
-
Paolo Abeni authored
Arseniy Krasnov says: ==================== vsock: handle writes to shutdowned socket this small patchset adds POSIX compliant behaviour on writes to the socket which was shutdowned with 'shutdown()' (both sides - local with SHUT_WR flag, peer - with SHUT_RD flag). According POSIX we must send SIGPIPE in such cases (but SIGPIPE is not send when MSG_NOSIGNAL is set). First patch is implemented in the same way as net/ipv4/tcp.c:tcp_sendmsg_locked(). It uses 'sk_stream_error()' function which handles EPIPE error. Another way is to use code from net/unix/af_unix.c:unix_stream_sendmsg() where same logic from 'sk_stream_error()' is implemented "from scratch", but it doesn't check 'sk_err' field. I think error from this field has more priority to be returned from syscall. So I guess it is better to reuse currently implemented 'sk_stream_error()' function. Test is also added. ==================== Link: https://lore.kernel.org/r/20230911202027.1928574-1-avkrasnov@salutedevices.comSigned-off-by:
-
Arseniy Krasnov authored
This adds two tests for 'shutdown()' call. It checks that SIGPIPE is sent when MSG_NOSIGNAL is not set and vice versa. Both flags SHUT_WR and SHUT_RD are tested. Signed-off-by:
Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Arseniy Krasnov authored
POSIX requires to send SIGPIPE on write to SOCK_STREAM socket which was shutdowned with SHUT_WR flag or its peer was shutdowned with SHUT_RD flag. Also we must not send SIGPIPE if MSG_NOSIGNAL flag is set. Signed-off-by:
-
- 13 Sep, 2023 8 commits
-
-
David S. Miller authored
Pedro Tammela says: ==================== selftests/tc-testing: add tests covering classid Patches 1-3 add missing tests covering classid behaviour on tdc for cls_fw, cls_route and cls_fw. This behaviour was recently fixed by valis[0]. Patch 4 comes from the development done in the previous patches as it turns out cls_route never returns meaningful errors. [0] https://lore.kernel.org/all/20230729123202.72406-1-jhs@mojatatu.com/ v2->v3: https://lore.kernel.org/all/20230825155148.659895-1-pctammela@mojatatu.com/ - Added changes that were left in the working tree (Jakub) - Fixed two typos in commit message titles - Added Victor tags v1->v2: https://lore.kernel.org/all/20230818163544.351104-1-pctammela@mojatatu.com/ - Drop u32 updates ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pedro Tammela authored
Use netlink extended ack and parsing policies to return more meaningful errors instead of the relying solely on errnos. Reviewed-by:
Victor Nogueira <victor@mojatatu.com> Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Signed-off-by:
-
Pedro Tammela authored
As discussed in '3044b16e', cls_u32 was handling the use of classid incorrectly. Add a test to check if it's conforming to the correct behaviour. Reviewed-by:
-
Pedro Tammela authored
As discussed in 'b80b829e', cls_route was handling the use of classid incorrectly. Add a test to check if it's conforming to the correct behaviour. Reviewed-by:
-
Pedro Tammela authored
As discussed in '76e42ae8', cls_fw was handling the use of classid incorrectly. Add a few tests to check if it's conforming to the correct behaviour. Reviewed-by:
-
Andy Gospodarek authored
Signed-off-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Pavan Chebbi pavan.chebbi@broadcom.com Signed-off-by:
Siva Reddy Kallam <siva.kallam@broadcom.com> Signed-off-by:
Prashant Sreedharan <prashant.sreedharan@broadcom.com> Reviewed-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Christophe JAILLET authored
Use devm_kasprintf() instead of hand writing it. This is less verbose and less error prone. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-09-11 (i40e, iavf) This series contains updates to i40e and iavf drivers. Andrii ensures all VSIs are cleaned up for remove in i40e. Brett reworks logic for setting promiscuous mode that can, currently, cause incorrect states on iavf. --- v2: - Remove redundant i40e_vsi_free_q_vectors() and kfree() calls (patch 1) v1: https://lore.kernel.org/netdev/20230905180521.887861-1-anthony.l.nguyen@intel.com/ ==================== Signed-off-by:
-
- 12 Sep, 2023 10 commits
-
-
Paolo Abeni authored
Eric Dumazet says: ==================== tcp: backlog processing optims First patches are mostly preparing the ground for the last one. Last patch of the series implements sort of ACK reduction only for the cases a TCP receiver is under high stress, which happens for high throughput flows. This gives us a ~20% increase of single TCP flow (100Gbit -> 120Gbit) ==================== Link: https://lore.kernel.org/r/20230911170531.828100-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
This idea came after a particular workload requested the quickack attribute set on routes, and a performance drop was noticed for large bulk transfers. For high throughput flows, it is best to use one cpu running the user thread issuing socket system calls, and a separate cpu to process incoming packets from BH context. (With TSO/GRO, bottleneck is usually the 'user' cpu) Problem is the user thread can spend a lot of time while holding the socket lock, forcing BH handler to queue most of incoming packets in the socket backlog. Whenever the user thread releases the socket lock, it must first process all accumulated packets in the backlog, potentially adding latency spikes. Due to flood mitigation, having too many packets in the backlog increases chance of unexpected drops. Backlog processing unfortunately shifts a fair amount of cpu cycles from the BH cpu to the 'user' cpu, thus reducing max throughput. This patch takes advantage of the backlog processing, and the fact that ACK are mostly cumulative. The idea is to detect we are in the backlog processing and defer all eligible ACK into a single one, sent from tcp_release_cb(). This saves cpu cycles on both sides, and network resources. Performance of a single TCP flow on a 200Gbit NIC: - Throughput is increased by 20% (100Gbit -> 120Gbit). - Number of generated ACK per second shrinks from 240,000 to 40,000. - Number of backlog drops per second shrinks from 230 to 0. Benchmark context: - Regular netperf TCP_STREAM (no zerocopy) - Intel(R) Xeon(R) Platinum 8481C (Saphire Rapids) - MAX_SKB_FRAGS = 17 (~60KB per GRO packet) This feature is guarded by a new sysctl, and enabled by default: /proc/sys/net/ipv4/tcp_backlog_ack_defer Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Dave Taht <dave.taht@gmail.com> Signed-off-by:
-
Eric Dumazet authored
__sk_flush_backlog() / sk_flush_backlog() are used when TCP recvmsg()/sendmsg() process large chunks, to not let packets in the backlog too long. It makes sense to call tcp_release_cb() to also process actions held in sk->sk_tsq_flags for smoother scheduling. Signed-off-by:
-
Eric Dumazet authored
sock_release_ownership() should only be called by user owning the socket lock. After prior commit, we can remove one condition. Signed-off-by:
-
Eric Dumazet authored
This partially reverts c3f9b018 ("tcp: tcp_release_cb() should release socket ownership"). prequeue has been removed by Florian in commit e7942d06 ("tcp: remove prequeue support") __tcp_checksum_complete_user() being gone, we no longer have to release socket ownership in tcp_release_cb(). This is a prereq for third patch in the series ("net: call prot->release_cb() when processing backlog"). Signed-off-by:
-
Andy Shevchenko authored
Use bitmap_zalloc() and bitmap_free() instead of hand-writing them. It is less verbose and it improves the type checking and semantic. While at it, add missing header inclusion (should be bitops.h, but with the above change it becomes bitmap.h). Reviewed-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230911131618.4159437-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Zhengchao Shao authored
Since commit 1202cdd6("Remove DECnet support from kernel") has been merged, all callers pass in the initial_ref value of 1 when they call dst_alloc(). Therefore, remove initial_ref when the dst_alloc() is declared and replace initial_ref with 1 in dst_alloc(). Also when all callers call dst_init(), the value of initial_ref is 1. Therefore, remove the input parameter initial_ref of the dst_init() and replace initial_ref with the value 1 in dst_init. Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20230911125045.346390-1-shaozhengchao@huawei.comSigned-off-by:
-
Paolo Abeni authored
MD Danish Anwar says: ==================== Add support for ICSSG on AM64x EVM This series adds support for ICSSG driver on AM64x EVM. First patch of the series adds compatible for AM64x EVM in icssg-prueth dt binding. Second patch adds support for AM64x compatible in the ICSSG driver. This series addresses comments on [v1] (which was posted as RFC). This series is based on the latest net-next/main. This series has no dependency. Changes from v1 to v2: *) Made the compatible list in patch 1 alphanumerically ordered as asked by Krzysztof. *) Dropped the RFC tag. *) Added RB tags of Andrew and Roger. [v1] https://lore.kernel.org/all/20230830113724.1228624-1-danishanwar@ti.com/ ==================== Link: https://lore.kernel.org/r/20230911054308.2163076-1-danishanwar@ti.comSigned-off-by:
-
MD Danish Anwar authored
Add AM64x ICSSG support which is similar to am65x SR2.0, but required: - all ring configured in exposed ring mode - always fill both original and buffer fields in cppi5 desc Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Roger Quadros <rogerq@kernel.org> Signed-off-by:
MD Danish Anwar <danishanwar@ti.com> Signed-off-by:
-
MD Danish Anwar authored
Add compatible for AM64x in icssg-prueth dt bindings. AM64x supports ICSSG similar to AM65x SR2.0. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
- 11 Sep, 2023 5 commits
-
-
Brett Creeley authored
Currently when configuring promiscuous mode on the AVF we detect a change in the netdev->flags. We use IFF_PROMISC and IFF_ALLMULTI to determine whether or not we need to request/release promiscuous mode and/or multicast promiscuous mode. The problem is that the AQ calls for setting/clearing promiscuous/multicast mode are treated separately. This leads to a case where we can trigger two promiscuous mode AQ calls in a row with the incorrect state. To fix this make a few changes. Use IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE instead of the previous IAVF_FLAG_AQ_[REQUEST|RELEASE]_[PROMISC|ALLMULTI] flags. In iavf_set_rx_mode() detect if there is a change in the netdev->flags in comparison with adapter->flags and set the IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE aq_required bit. Then in iavf_process_aq_command() only check for IAVF_FLAG_CONFIGURE_PROMISC_MODE and call iavf_set_promiscuous() if it's set. In iavf_set_promiscuous() check again to see which (if any) promiscuous mode bits have changed when comparing the netdev->flags with the adapter->flags. Use this to set the flags which get sent to the PF driver. Add a spinlock that is used for updating current_netdev_promisc_flags and only allows one promiscuous mode AQ at a time. [1] Fixes the fact that we will only have one AQ call in the aq_required queue at any one time. [2] Streamlines the change in promiscuous mode to only set one AQ required bit. [3] This allows us to keep track of the current state of the flags and also makes it so we can take the most recent netdev->flags promiscuous mode state. [4] This fixes the problem where a change in the netdev->flags can cause IAVF_FLAG_AQ_CONFIGURE_PROMISC_MODE to be set in iavf_set_rx_mode(), but cleared in iavf_set_promiscuous() before the change is ever made via AQ call. Fixes: 47d34839 ("i40evf: Add driver support for promiscuous mode") Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
Ahmed Zaki <ahmed.zaki@intel.com> Tested-by:
Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Andrii Staikov authored
Instead of freeing memory of a single VSI, make sure the memory for all VSIs is cleared before releasing VSIs. Add releasing of their resources in a loop with the iteration number equal to the number of allocated VSIs. Fixes: 41c445ff ("i40e: main driver core") Signed-off-by:
Andrii Staikov <andrii.staikov@intel.com> Signed-off-by:
Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by:
-
Lorenzo Bianconi authored
MT7988 SoC support 3 NICs. Fix pse_port configuration in mtk_flow_set_output_device routine if the traffic is offloaded to eth2. Rely on mtk_pse_port definitions. Fixes: 88efedf5 ("net: ethernet: mtk_eth_soc: enable nft hw flowtable_offload for MT7988 SoC") Signed-off-by:
-
Daniel Golle authored
Variable dma_addr in function mtk_poll_rx can be uninitialized on some of the error paths. In practise this doesn't matter, even random data present in uninitialized stack memory can safely be used in the way it happens in the error path. However, in order to make Smatch happy make sure the variable is always initialized. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
-
Shigeru Yoshida authored
syzbot reported a memory leak like below: BUG: memory leak unreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline] [<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline] [<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748 [<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd In kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak. This patch fixes this issue by properly updating the last allocated skb in 'last_skb'. Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module") Reported-and-tested-by: syzbot+6f98de741f7dbbfc4ccb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6f98de741f7dbbfc4ccbSigned-off-by:Shigeru Yoshida <syoshida@redhat.com> Signed-off-by:
-
