- 30 Nov, 2022 9 commits
-
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== mptcp: MSG_FASTOPEN and TFO listener side support Before this series, only the initiator of a connection was able to combine both TCP FastOpen and MPTCP when using TCP_FASTOPEN_CONNECT socket option. These new patches here add (in theory) the full support of TFO with MPTCP, which means: - MSG_FASTOPEN sendmsg flag support (patch 1/8) - TFO support for the listener side (patches 2-5/8) - TCP_FASTOPEN socket option (patch 6/8) - TCP_FASTOPEN_KEY socket option (patch 7/8) To support TFO for the server side, a few preparation patches are needed (patches 2 to 5/8). Some of them were inspired by a previous work from Benjamin Hesmans. Note that TFO support with MPTCP has been validated with selftests (patch 8/8) but also with Packetdrill tests running with a modified but still very WIP version supporting MPTCP. Both the modified tool and the tests are available online: https://github.com/multipath-tcp/packetdrill/ ==================== Link: https://lore.kernel.org/r/20221125222958.958636-1-matthieu.baerts@tessares.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Dmytro Shytyi authored
This patch first adds TFO support in mptcp_connect.c. This can be enabled via a new option: -o MPTFO. Once enabled, the TCP_FASTOPEN socket option is enabled for the server side and a sendto() with MSG_FASTOPEN is used instead of a connect() for the client side. Note that the first SYN has a limit of bytes it can carry. In other words, it is allowed to send less data than the provided one. We then need to track more status info to properly allow the next sendmsg() starting from the next part of the data to send the rest. Also in TFO scenarios, we need to completely spool the partially xmitted buffer -- and account for that -- before starting sendfile/mmap xmit, otherwise the relevant tests will fail. Co-developed-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Dmytro Shytyi <dmytro@shytyi.net> Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Matthieu Baerts authored
The goal of this socket option is to set different keys per listener, see commit 1fba70e5 ("tcp: socket option to set TCP fast open key") for more details about this socket option. The only thing to do here with MPTCP is to relay the request to the first subflow like it is already done for the other TCP_FASTOPEN* socket options. Acked-by:
-
Dmytro Shytyi authored
The TCP_FASTOPEN socket option is one way for the application to tell the kernel TFO support has to be enabled for the listener socket. The only thing to do here with MPTCP is to relay the request to the first subflow like it is already done for the other TCP_FASTOPEN* socket options. Acked-by:
-
Dmytro Shytyi authored
The send_synack() needs to be overridden for MPTCP to support TFO for two reasons: - There is not be enough space in the TCP options if the TFO cookie has to be added in the SYN+ACK with other options: MSS (4), SACK OK (2), Timestamps (10), Window Scale (3+1), TFO (10+2), MP_CAPABLE (12). MPTCPv1 specs -- RFC 8684, section B.1 [1] -- suggest to drop the TCP timestamps option in this case. - The data received in the SYN has to be handled: the SKB can be dequeued from the subflow sk and transferred to the MPTCP sk. Counters need to be updated accordingly and the application can be notified at the end because some bytes have been received. [1] https://www.rfc-editor.org/rfc/rfc8684.html#section-b.1Co-developed-by:
-
Dmytro Shytyi authored
With fastopen in place, the first subflow socket is created before the MPC handshake completes, and we need to properly initialize the sequence numbers at MPC ACK reception. Co-developed-by:
-
Paolo Abeni authored
Currently the initial ack sequence is generated on demand whenever it's requested and the remote key is handy. The relevant code is scattered in different places and can lead to multiple, unneeded, crypto operations. This change consolidates the ack sequence generation code in a single helper, storing the sequence number at the subflow level. The above additionally saves a few conditional in fast-path and will simplify the upcoming fast-open implementation. Signed-off-by:
-
Paolo Abeni authored
Currently in the receive path we don't need to discriminate between MPC SYN, MPC SYN-ACK and MPC ACK, but soon the fastopen code will need that info to properly track the fully established status. Track the exact MPC suboption type into the receive opt bitmap. No functional change intended. Signed-off-by:
-
Dmytro Shytyi authored
Since commit 54f1944e ("mptcp: factor out mptcp_connect()"), all the infrastructure is now in place to support the MSG_FASTOPEN flag, we just need to call into the fastopen path in mptcp_sendmsg(). Co-developed-by:
Benjamin Hesmans <benjamin.hesmans@tessares.net> Signed-off-by:
-
- 29 Nov, 2022 31 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
tools/lib/bpf/ringbuf.c 927cbb47 ("libbpf: Handle size overflow for ringbuf mmap") b486d19a ("libbpf: checkpatch: Fixed code alignments in ringbuf.c") https://lore.kernel.org/all/20221121122707.44d1446a@canb.auug.org.au/Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from bpf, can and wifi. Current release - new code bugs: - eth: mlx5e: - use kvfree() in mlx5e_accel_fs_tcp_create() - MACsec, fix RX data path 16 RX security channel limit - MACsec, fix memory leak when MACsec device is deleted - MACsec, fix update Rx secure channel active field - MACsec, fix add Rx security association (SA) rule memory leak Previous releases - regressions: - wifi: cfg80211: don't allow multi-BSSID in S1G - stmmac: set MAC's flow control register to reflect current settings - eth: mlx5: - E-switch, fix duplicate lag creation - fix use-after-free when reverting termination table Previous releases - always broken: - ipv4: fix route deletion when nexthop info is not specified - bpf: fix a local storage BPF map bug where the value's spin lock field can get initialized incorrectly - tipc: re-fetch skb cb after tipc_msg_validate - wifi: wilc1000: fix Information Element parsing - packet: do not set TP_STATUS_CSUM_VALID on CHECKSUM_COMPLETE - sctp: fix memory leak in sctp_stream_outq_migrate() - can: can327: fix potential skb leak when netdev is down - can: add number of missing netdev freeing on error paths - aquantia: do not purge addresses when setting the number of rings - wwan: iosm: - fix incorrect skb length leading to truncated packet - fix crash in peek throughput test due to skb UAF" * tag 'net-6.1-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (79 commits) net: ethernet: renesas: ravb: Fix promiscuous mode after system resumed MAINTAINERS: Update maintainer list for chelsio drivers ionic: update MAINTAINERS entry sctp: fix memory leak in sctp_stream_outq_migrate() packet: do not set TP_STATUS_CSUM_VALID on CHECKSUM_COMPLETE net/mlx5: Lag, Fix for loop when checking lag Revert "net/mlx5e: MACsec, remove replay window size limitation in offload path" net: marvell: prestera: Fix a NULL vs IS_ERR() check in some functions net: tun: Fix use-after-free in tun_detach() net: mdiobus: fix unbalanced node reference count net: hsr: Fix potential use-after-free tipc: re-fetch skb cb after tipc_msg_validate mptcp: fix sleep in atomic at close time mptcp: don't orphan ssk in mptcp_close() dsa: lan9303: Correct stat name ipv4: Fix route deletion when nexthop info is not specified net: wwan: iosm: fix incorrect skb length net: wwan: iosm: fix crash in peek throughput test net: wwan: iosm: fix dma_alloc_coherent incompatible pointer type net: wwan: iosm: fix kernel test robot reported error ... -
Yuan Can authored
As the nla_nest_start() may fail with NULL returned, the return value should be checked. Note that this is not a real bug, nothing will break here. The next nla_put() will fail as well and we'll bail (and nla_nest_cancel() can handle NULL). But we keep getting those "fixes" so whatever. Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20221129013934.55184-1-yuancan@huawei.comSigned-off-by:
-
Yoshihiro Shimoda authored
After system resumed on some environment board, the promiscuous mode is disabled because the SoC turned off. So, call ravb_set_rx_mode() in the ravb_resume() to fix the issue. Reported-by:
Tho Vu <tho.vu.wh@renesas.com> Fixes: 0184165b ("ravb: add sleep PM suspend/resume support") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20221128065604.1864391-1-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Ayush Sawal authored
This updates the maintainers for chelsio inline crypto drivers and chelsio crypto drivers. Signed-off-by:
Ayush Sawal <ayush.sawal@chelsio.com> Link: https://lore.kernel.org/r/20221128231348.8225-1-ayush.sawal@chelsio.comSigned-off-by:
-
Shannon Nelson authored
Now that Pensando is a part of AMD we need to update a couple of addresses. We're keeping the mailing list address for the moment, but that will likely change in the near future. Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20221129011734.20849-1-shannon.nelson@amd.comSigned-off-by:
-
Zhengchao Shao authored
When sctp_stream_outq_migrate() is called to release stream out resources, the memory pointed to by prio_head in stream out is not released. The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60 [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770 [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0 [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30 [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0 [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0 [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120 [<ffffffff8755446a>] __sys_sendto+0x23a/0x340 [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0 [<ffffffff89978b49>] do_syscall_64+0x39/0xb0 [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://syzkaller.appspot.com/bug?exrid=29c402e56c4760763cc0 Fixes: 637784ad ("sctp: introduce priority based stream scheduler") Reported-by: syzbot+29c402e56c4760763cc0@syzkaller.appspotmail.com Signed-off-by:Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/20221126031720.378562-1-shaozhengchao@huawei.comSigned-off-by:
-
Willem de Bruijn authored
CHECKSUM_COMPLETE signals that skb->csum stores the sum over the entire packet. It does not imply that an embedded l4 checksum field has been validated. Fixes: 682f048b ("af_packet: pass checksum validation status to the user") Signed-off-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20221128161812.640098-1-willemdebruijn.kernel@gmail.comSigned-off-by:
-
Chris Mi authored
The cited commit adds a for loop to check if each port supports lag or not. But dev is not initialized correctly. Fix it by initializing dev for each iteration. Fixes: e87c6a83 ("net/mlx5: E-switch, Fix duplicate lag creation") Signed-off-by:
Chris Mi <cmi@nvidia.com> Reported-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20221129093006.378840-2-saeed@kernel.orgSigned-off-by:
-
Saeed Mahameed authored
This reverts commit c0071be0. The cited commit removed the validity checks which initialized the window_sz and never removed the use of the now uninitialized variable, so now we are left with wrong value in the window size and the following clang warning: [-Wuninitialized] drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c:232:45: warning: variable 'window_sz' is uninitialized when used here MLX5_SET(macsec_aso, aso_ctx, window_size, window_sz); Revet at this time to address the clang issue due to lack of time to test the proper solution. Fixes: c0071be0 ("net/mlx5e: MACsec, remove replay window size limitation in offload path") Signed-off-by:
-
Yu Xiao authored
Add support for reporting link modes, including `Supported link modes` and `Advertised link modes`, via ethtool $DEV. A new command `SPCODE_READ_MEDIA` is added to read info from management firmware. Also, the mapping table `nfp_eth_media_table` associates the link modes between NFP and kernel. Both of them help to support this ability. Signed-off-by:
Yu Xiao <yu.xiao@corigine.com> Reviewed-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Link: https://lore.kernel.org/r/20221125113030.141642-1-simon.horman@corigine.comSigned-off-by:
-
Jiri Pirko authored
As the return value is not 0 only in case there is no such notifier block registered, add a WARN_ON_ONCE() to yell about it. Suggested-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20221125100255.1786741-1-jiri@resnulli.usSigned-off-by:
-
Paolo Abeni authored
Horatiu Vultur says: ==================== Add support for lan966x IS2 VCAP This provides initial support for lan966x for 'tc' traffic control userspace tool and its flower filter. For this is required to use the VCAP library. Currently supported flower filter keys and actions are: - source and destination MAC address keys - trap action ==================== Link: https://lore.kernel.org/r/20221125095010.124458-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
On lan966x the layout of the vcap memory is different than on sparx5. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Implement vcap_operations and enable default port keyset configuration for each port. Now it is possible actually write/read/move entries in the VCAP. Signed-off-by:
-
Horatiu Vultur authored
Extend matchall with action goto. This is needed to enable the lookup in the VCAP. It is needed to connect chain 0 to a chain that is recognized by the HW. Signed-off-by:
-
Horatiu Vultur authored
Currently the only supported action is ACTION_TRAP and the only dissector is ETH_ADDRS. Others will be added in future patches. Signed-off-by:
-
Horatiu Vultur authored
Add registers used to access vcap controller. Signed-off-by:
-
Horatiu Vultur authored
This provides the lan966x is2 model and adds it to the vcap control instance that will be provided to the vcap API. Signed-off-by:
-
Horatiu Vultur authored
When lan966x driver is initialized, initialize also the VCAP module for lan966x. Signed-off-by:
-
Horatiu Vultur authored
Add the keysets, keys, actionsets and actions used by lan966x in IS2. Signed-off-by:
-
Horatiu Vultur authored
Currently there are 2 files that contain the keyfields, keys, actionfields and actions. First file is used by the kunit while the second one is used by VCAP api. The header file that is used by kunit is just a super set of the of the header file used by VCAP api. Therefore not to have duplicate information in different files which is also harder to maintain, create a single file that is used both by API and by kunit. Signed-off-by:
-
Shang XiaoJing authored
rhashtable_lookup_fast() returns NULL when failed instead of error pointer. Fixes: 396b80cb ("net: marvell: prestera: Add neighbour cache accounting") Fixes: 0a23ae23 ("net: marvell: prestera: Add router nexthops ABI") Signed-off-by:
Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20221125012751.23249-1-shangxiaojing@huawei.comSigned-off-by:
-
Shigeru Yoshida authored
syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. Fixes: 83c1f36f ("tun: send netlink notification when the device is modified") Reported-by: syzbot+106f9b687cd64ee70cd1@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=96eb7f1ce75ef933697f24eeab928c4a716edefe [1] Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Link: https://lore.kernel.org/r/20221124175134.1589053-1-syoshida@redhat.comSigned-off-by:
-
Paolo Abeni authored
Lorenzo Bianconi says: ==================== refactor mtk_wed code to introduce SER support Refactor mtk_wed support in order to introduce proper integration for hw reset between mtk_eth_soc/mtk_wed and mt76 drivers. ==================== Link: https://lore.kernel.org/r/cover.1669303154.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce reset parameter to mtk_wed_tx_ring_setup signature. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mtk_wed_rx_reset routine in order to reset rx DMA for Wireless Ethernet Dispatcher available on MT7986 SoC. Co-developed-by:
-
Lorenzo Bianconi authored
Update mtk_wed_stop routine and rename old mtk_wed_stop() to mtk_wed_deinit(). This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Remove duplicated code. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Move MTK_WDMA_RESET_IDX configuration in mtk_wdma_rx_reset routine. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Paolo Abeni authored
Miquel Raynal says: ==================== Marvell nvmem mac addresses support Now that we are aligned on how to make information available from static storage media to drivers like Ethernet controller drivers or switch drivers by using nvmem cells and going through the whole nvmem infrastructure, here are two driver updates to reflect these changes. Prior to the driver updates, I propose: * Reverting binding changes which should have never been accepted like that. * A conversion of the (old) Prestera and DFX server bindings (optional, can be dropped if not considered necessary). * A better description of the more recent Prestera PCI switch. Please mind that this series cannot break anything since retrieving the MAC address Prestera driver has never worked upstream, because the (ONIE tlv) driver supposed to export the MAC address has not been accepted in its original form and has been updated to the nvmem-layout infrastructure (bindings have been merged, the code remains to be applied). ==================== Link: https://lore.kernel.org/r/20221124111556.264647-1-miquel.raynal@bootlin.comSigned-off-by:
-
