From: allison.henderson@oracle.com To: netdev@vger.kernel.org Cc: linux-kselftest@vger.kernel.org, rds-devel@oss.oracle.com, linux-rdma@vger.kernel.org, oberpar@linux.ibm.com, chuck.lever@oracle.com, vegard.nossum@oracle.com, Allison Henderson Subject: [PATCH net-next v1 0/3] selftests: rds selftest Date: Tue, 25 Jun 2024 18:28:31 -0700 Message-Id: <20240626012834.5678-1-allison.henderson@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.netdev:355035 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-rdma Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Allison Henderson Hi All, This series is a new selftest that Vegard, Chuck and myself have been working on to provide some test coverage for rds. I've made quite a few updates since the rfc sent a few weeks ago: I've added several knobs to the script to tune network turbulance, and documented their usage in the README.txt. By default these options are left off. Added an extra flag to specify log location I've also added a flag to the config.sh to skip gcov configurations if the coverage report is not desired. run.sh has been adapted to skip the report if the required configs are not present, or if the required packages are not available A time out has been added to prevent the test from hanging indefinitely The previous gcov issues have been resolved with an appropriate gcov patch, as well as some extra logic to detect incompatible gcov and gcc versions. The shellcheck nits reported in the last review have been addressed In order to return an appropriate exit code, the run.sh script has been adapted to analyze the test.py strace, and determine if the test passed, failed or timed out. RDS specific GCOV configs have been documented under Documentation/dev-tools/gcov.rst Questions and comments appreciated. Thanks everyone! Allison Vegard Nossum (3): .gitignore: add .gcda files net: rds: add option for GCOV profiling selftests: rds: add testing infrastructure .gitignore | 1 + Documentation/dev-tools/gcov.rst | 11 + MAINTAINERS | 1 + net/rds/Kconfig | 9 + net/rds/Makefile | 5 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/net/rds/Makefile | 13 + tools/testing/selftests/net/rds/README.txt | 41 ++++ tools/testing/selftests/net/rds/config.sh | 56 +++++ tools/testing/selftests/net/rds/init.sh | 69 ++++++ tools/testing/selftests/net/rds/run.sh | 271 +++++++++++++++++++++ tools/testing/selftests/net/rds/test.py | 251 +++++++++++++++++++ 12 files changed, 729 insertions(+) create mode 100644 tools/testing/selftests/net/rds/Makefile create mode 100644 tools/testing/selftests/net/rds/README.txt create mode 100755 tools/testing/selftests/net/rds/config.sh create mode 100755 tools/testing/selftests/net/rds/init.sh create mode 100755 tools/testing/selftests/net/rds/run.sh create mode 100644 tools/testing/selftests/net/rds/test.py -- 2.25.1 . From: Chen Hanxiao To: Simon Horman , Julian Anastasov , Pablo Neira Ayuso , Jozsef Kadlecsik , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: netdev@vger.kernel.org, lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org Subject: [PATCH net-next] ipvs: properly dereference pe in ip_vs_add_service Date: Wed, 26 Jun 2024 16:11:59 +0800 Message-Id: <20240626081159.1405-1-chenhx.fnst@fujitsu.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Xref: photonic.trudheim.com org.kernel.vger.netdev:355043 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.lvs-devel,org.kernel.vger.netfilter-devel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Use rcu_dereference_protected to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression Fixes: 39b972231536 ("ipvs: handle connections started by real-servers") Signed-off-by: Chen Hanxiao --- net/netfilter/ipvs/ip_vs_ctl.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c index b6d0dcf3a5c3..925e2143ba15 100644 --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -1369,7 +1369,7 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u, { int ret = 0; struct ip_vs_scheduler *sched = NULL; - struct ip_vs_pe *pe = NULL; + struct ip_vs_pe *pe = NULL, *tmp_pe = NULL; struct ip_vs_service *svc = NULL; int ret_hooks = -1; @@ -1468,7 +1468,8 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u, atomic_inc(&ipvs->ftpsvc_counter); else if (svc->port == 0) atomic_inc(&ipvs->nullsvc_counter); - if (svc->pe && svc->pe->conn_out) + tmp_pe = rcu_dereference_protected(svc->pe, 1); + if (tmp_pe && tmp_pe->conn_out) atomic_inc(&ipvs->conn_out_counter); /* Count only IPv4 services for old get/setsockopt interface */ -- 2.39.1 . From: Daniel Borkmann To: kuba@kernel.org Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Daniel Borkmann , Lex Siegel , Neil Brown Subject: [PATCH net] net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket Date: Wed, 26 Jun 2024 11:13:47 +0200 Message-Id: <72b5939b13efd4fde6e9c0f9fb00edd314f4bcce.1719392816.git.daniel@iogearbox.net> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.netdev:355049 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.bpf Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request(). Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect") Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind") Co-developed-by: Lex Siegel Signed-off-by: Lex Siegel Signed-off-by: Daniel Borkmann Cc: Neil Brown Link: https://github.com/cilium/cilium/issues/33395 Link: https://lore.kernel.org/bpf/171374175513.12877.8993642908082014881@noble.neil.brown.name --- [ Fixes tags are set to the orig connect commit so that stable team can pick this up. ] net/sunrpc/xprtsock.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index dfc353eea8ed..0e1691316f42 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -2441,6 +2441,13 @@ static void xs_tcp_setup_socket(struct work_struct *work) transport->srcport = 0; status = -EAGAIN; break; + case -EPERM: + /* Happens, for instance, if a BPF program is preventing + * the connect. Remap the error so upper layers can better + * deal with it. + */ + status = -ECONNREFUSED; + fallthrough; case -EINVAL: /* Happens, for instance, if the user specified a link * local IPv6 address without a scope-id. -- 2.21.0 . From: Dragos Tatulea Subject: [PATCH vhost v2 00/24] vdpa/mlx5: Pre-create HW VQs to reduce LM downtime Date: Wed, 26 Jun 2024 13:26:36 +0300 Message-ID: <20240626-stage-vdpa-vq-precreate-v2-0-560c491078df@nvidia.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?utf-8?q?Eugenio_P=C3=A9rez?= , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Si-Wei Liu CC: , , , , Cosmin Ratiu , Dragos Tatulea , Zhu Yanjun Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1259392 org.kernel.vger.netdev:355058 Newsgroups: org.kernel.vger.linux-kernel,dev.linux.lists.virtualization,org.kernel.vger.linux-rdma,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail According to the measurements for vDPA Live Migration downtime [0], one large source of downtime is the creation of hardware VQs and their associated resources on the devices on the destination VM. Previous series ([1], [2]) addressed the source part of the Live Migration downtime. This series addresses the destination part: instead of creating hardware VQs and their dependent resources when the device goes into the DRIVER_OK state (which is during downtime), create "blank" VQs at device creation time and only modify them to the received configuration before starting the VQs (DRIVER_OK state). The caveat here is that mlx5_vdpa VQs don't support modifying the VQ size. VQs will be created with a convenient default size and when this size is changed, they will be recreated. The beginning of the series consists of refactorings and preparation. After that, some preparations are made: - Allow creation of "blank" VQs by not configuring them during create_virtqueue() if there are no modified fields. - The VQ Init to Ready state transition is consolidated into the resume_vq(). - Add error handling to suspend/resume code paths. Then VQs are created at device creation time. Finally, the special cases that need full VQ resource recreation are handled. On a 64 CPU, 256 GB VM with 1 vDPA device of 16 VQps, the full VQ resource creation + resume time was ~370ms. Now it's down to 60 ms (only VQ config and resume). The measurements were done on a ConnectX6DX based vDPA device. [0] https://lore.kernel.org/qemu-devel/1701970793-6865-1-git-send-email-si-wei.liu@oracle.com/ [1] https://lore.kernel.org/lkml/20231018171456.1624030-2-dtatulea@nvidia.com [2] https://lore.kernel.org/lkml/20231219180858.120898-1-dtatulea@nvidia.com --- Changes in v2: - Renamed a function based on v1 review. - Addressed small nits from v1 review. - Added improvement numbers in commit message instead of only cover letter. - Link to v1: https://lore.kernel.org/r/20240617-stage-vdpa-vq-precreate-v1-0-8c0483f0ca2a@nvidia.com --- Dragos Tatulea (24): vdpa/mlx5: Clarify meaning thorough function rename vdpa/mlx5: Make setup/teardown_vq_resources() symmetrical vdpa/mlx5: Drop redundant code vdpa/mlx5: Drop redundant check in teardown_virtqueues() vdpa/mlx5: Iterate over active VQs during suspend/resume vdpa/mlx5: Remove duplicate suspend code vdpa/mlx5: Initialize and reset device with one queue pair vdpa/mlx5: Clear and reinitialize software VQ data on reset vdpa/mlx5: Rename init_mvqs vdpa/mlx5: Add support for modifying the virtio_version VQ field vdpa/mlx5: Add support for modifying the VQ features field vdpa/mlx5: Set an initial size on the VQ vdpa/mlx5: Start off rqt_size with max VQPs vdpa/mlx5: Set mkey modified flags on all VQs vdpa/mlx5: Allow creation of blank VQs vdpa/mlx5: Accept Init -> Ready VQ transition in resume_vq() vdpa/mlx5: Add error code for suspend/resume VQ vdpa/mlx5: Consolidate all VQ modify to Ready to use resume_vq() vdpa/mlx5: Forward error in suspend/resume device vdpa/mlx5: Use suspend/resume during VQP change vdpa/mlx5: Pre-create hardware VQs at vdpa .dev_add time vdpa/mlx5: Re-create HW VQs under certain conditions vdpa/mlx5: Don't reset VQs more than necessary vdpa/mlx5: Don't enable non-active VQs in .set_vq_ready() drivers/vdpa/mlx5/net/mlx5_vnet.c | 429 +++++++++++++++++++++++++------------ drivers/vdpa/mlx5/net/mlx5_vnet.h | 1 + include/linux/mlx5/mlx5_ifc_vdpa.h | 2 + 3 files changed, 293 insertions(+), 139 deletions(-) --- base-commit: c8fae27d141a32a1624d0d0d5419d94252824498 change-id: 20240617-stage-vdpa-vq-precreate-76df151bed08 Best regards, -- Dragos Tatulea . From: Sky Huang To: Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Daniel Golle , Qingfang Deng , SkyLake Huang , Matthias Brugger , AngeloGioacchino Del Regno , , , , CC: Steven Liu , SkyLake.Huang Subject: [PATCH net-next v9 00/13] net: phy: mediatek: Introduce mtk-phy-lib and add 2.5Gphy support Date: Wed, 26 Jun 2024 18:43:16 +0800 Message-ID: <20240626104329.11426-1-SkyLake.Huang@mediatek.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1259444 org.kernel.vger.netdev:355086 Newsgroups: org.kernel.vger.linux-kernel,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: "SkyLake.Huang" This patch series integrate MediaTek's built-in Ethernet PHY helper functions into mtk-phy-lib and add more functions into it. Also, add support for 2.5Gphy on MT7988 SoC. Signed-off-by: SkyLake.Huang --- Changes in v2: - Apply correct PATCH tag. - Break LED/Token ring/Extend-link-pulse-time features into 3 patches. - Fix contents according to v1 comments. Changes in v3: - Rebase code and now this patch series can apply to net-next tree. [PATCH 4/5] Refactor mtk_gphy_cl22_read_status() with genphy_read_status(). [PATCH 5/5] 1. Add range check for firmware. 2. Fix c45_ids.mmds_present in probe function. 3. Still use genphy_update_link() in read_status because genphy_c45_read_link() can't correct detect link on this phy. Changes in v4: [PATCH 4/5] 1. Change extend_an_new_lp_cnt_limit()'s return type and all return values 2. Refactor comments in extend_an_new_lp_cnt_limit() [PATCH 5/5] 1. Move firmware loading function to mt798x_2p5ge_phy_load_fw() 2. Add AN disable warning in mt798x_2p5ge_phy_config_aneg() 3. Clarify the HDX comments in mt798x_2p5ge_phy_get_features() Changes in v5: - Fix syntax errors of comments in drivers/net/phy/mediatek/* [PATCH 1/5] - Change MEDIATEK_GE_SOC_PHY from bool back to tristate. [PATCH 5/5] 1. Move md32_en_cfg_base & pmb_addr to local variables to achieve symmetric code. 2. Print out firmware date code & version. 3. Don't return error if LED pinctrl switching fails. Also, add comments to this unusual operations. 4. Return -EOPNOTSUPP for AN off case in config_aneg(). Changes in v6: - Re-arrange patch and changes description in cover letter. - Contraint code inside 80 columns wide. [PATCH 4/5] 1. Add LP_DETECTED so extend_an_new_lp_cnt_limit() won't be called every time we poll the PHY for its status. It'll be called only when cable is plugged in and 1G training starts. 2. Call phy_read_paged() instead of calling phy_select_page() & phy_restore_page() pair. [PATCH 5/5] 1. Force casting (fw->data + MT7988_2P5GE_PMB_SIZE - 8) with __be16. 2. Remove parens on RHS of "phydev->c45_ids.mmds_present |=". 3. Add PHY_INTERFACE_MODE_INTERNAL check in mt798x_2p5ge_phy_get_rate_matching() 4. Arrange local variables in reverse Xmas tree order. Changes in v7: [PATCH 5/5] 1. Add phy mode check(PHY_INTERFACE_MODE_INTERNAL) in config_init(). 2. Always return RATE_MATCH_PAUSE in get_rate_matching(). Changes in v8: - Make sure that each variables in drivers/net/phy/mediatek/* follows reverse Xmas tree order. - Split v7 patches in this way: [PATCH net-next v7 1/5] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers -> [PATCH net-next v8 01/13] net: phy: mediatek: Re-organize MediaTek ethernet phy drivers -> [PATCH net-next v8 02/13] net: phy: mediatek: Fix spelling errors and rearrange variables [PATCH net-next v7 2/5] net: phy: mediatek: Move LED and read/write page helper functions into mtk phy lib -> [PATCH net-next v8 03/13] net: phy: mediatek: Move LED helper functions into mtk phy lib -> [PATCH net-next v8 04/13] net: phy: mediatek: Improve readability of mtk-phy-lib.c's mtk_phy_led_hw_ctrl_set() -> [PATCH net-next v8 05/13] net: phy: mediatek: Integrate read/write page helper functions -> [PATCH net-next v8 06/13] net: phy: mediatek: Hook LED helper functions in mtk-ge.c -> [PATCH net-next v8 07/13] net: phy: mediatek: add MT7530 & MT7531's PHY ID macros -> [PATCH net-next v8 08/13] net: phy: mediatek: Change mtk-ge-soc.c line wrapping [PATCH net-next v7 3/5] net: phy: mediatek: Add token ring access helper functions in mtk-phy-lib -> [PATCH net-next v8 09/13] net: phy: mediatek: Add token ring access helper functions in mtk-phy-lib [PATCH net-next v7 4/5] net: phy: mediatek: Extend 1G TX/RX link pulse time -> [PATCH net-next v8 10/13] net: phy: mediatek: Extend 1G TX/RX link pulse time [PATCH net-next v7 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988 -> [PATCH net-next v8 11/13] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988 - Create another 2 patches to: - fix alignment in callback functions declarations in mtk-ge.c & mtk-ge-soc.c - Remove unnecessary outer parens of "supported_triggers" var - Replace token ring API, tr* & __tr* with mtk_tr* & __mtk_tr* and fix alignment. Changes in v9: [PATCH 03/13][PATCH 06/13][PATCH 11/13] - Add mtk_phy_led_num_dly_cfg helper function to check led number & set delay on/off time. [PATCH 07/13][PATCH 12/13] - Remove "mt753x_phy_led_hw_is_supported," callback function hook in MT7530 part of mtk-ge.c [PATCH 09/13] - Replace EEE1000_SELECT_SIGNEL_DETECTION_FROM_DFE with EEE1000_SELECT_SIGNAL_DETECTION_FROM_DFE. (SIGNEL->SIGNAL.) [PATCH 11/13] - Add MODULE_FIRMARE() - Replace "MT7988_2P5GE_PMB" with "MT7988_2P5GE_PMB_FW" so we can recognize it literally. - Remove unused macro names: 1. BASE100T_STATUS_EXTEND 2. BASE1000T_STATUS_EXTEND 3. EXTEND_CTRL_AND_STATUS 4. PHY_AUX_DPX_MASK --- SkyLake.Huang (13): net: phy: mediatek: Re-organize MediaTek ethernet phy drivers net: phy: mediatek: Fix spelling errors and rearrange variables net: phy: mediatek: Move LED helper functions into mtk phy lib net: phy: mediatek: Improve readability of mtk-phy-lib.c's mtk_phy_led_hw_ctrl_set() net: phy: mediatek: Integrate read/write page helper functions net: phy: mediatek: Hook LED helper functions in mtk-ge.c net: phy: mediatek: add MT7530 & MT7531's PHY ID macros net: phy: mediatek: Change mtk-ge-soc.c line wrapping net: phy: mediatek: Add token ring access helper functions in mtk-phy-lib net: phy: mediatek: Extend 1G TX/RX link pulse time net: phy: add driver for built-in 2.5G ethernet PHY on MT7988 net: phy: mediatek: Fix alignment in callback functions' hook net: phy: mediatek: Remove unnecessary outer parens of "supported_triggers" var MAINTAINERS | 7 +- drivers/net/phy/Kconfig | 17 +- drivers/net/phy/Makefile | 3 +- drivers/net/phy/mediatek-ge.c | 111 --- drivers/net/phy/mediatek/Kconfig | 38 + drivers/net/phy/mediatek/Makefile | 5 + drivers/net/phy/mediatek/mtk-2p5ge.c | 431 +++++++++++ .../mtk-ge-soc.c} | 693 ++++++++---------- drivers/net/phy/mediatek/mtk-ge.c | 243 ++++++ drivers/net/phy/mediatek/mtk-phy-lib.c | 450 ++++++++++++ drivers/net/phy/mediatek/mtk.h | 119 +++ 11 files changed, 1585 insertions(+), 532 deletions(-) delete mode 100644 drivers/net/phy/mediatek-ge.c create mode 100644 drivers/net/phy/mediatek/Kconfig create mode 100644 drivers/net/phy/mediatek/Makefile create mode 100644 drivers/net/phy/mediatek/mtk-2p5ge.c rename drivers/net/phy/{mediatek-ge-soc.c => mediatek/mtk-ge-soc.c} (73%) create mode 100644 drivers/net/phy/mediatek/mtk-ge.c create mode 100644 drivers/net/phy/mediatek/mtk-phy-lib.c create mode 100644 drivers/net/phy/mediatek/mtk.h -- 2.18.0 . Date: Wed, 26 Jun 2024 14:58:17 +0300 From: Ido Schimmel To: gnault@redhat.com, netdev@vger.kernel.org Subject: Matching on DSCP with IPv4 FIB rules Message-ID: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.netdev:355103 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi Guillaume, everyone, We have users that would like to direct traffic to a routing table based on the DSCP value in the IP header. While this can be done using IPv6 FIB rules, it cannot be done using IPv4 FIB rules as the kernel only allows such rules to match on the three TOS bits from RFC 791 (lower three DSCP bits). See more info in Guillaume's excellent presentation here [1]. Extending IPv4 FIB rules to match on DSCP is not easy because of how inconsistently the TOS field in the IPv4 flow information structure (i.e., 'struct flowi4::flowi4_tos') is initialized and handled throughout the networking stack. Redefining the field using 'dscp_t' and removing the masking of the upper three DSCP bits is not an option as it will change existing behavior. For example, an incoming IPv4 packet with a DS field of 0xfc will no longer match a FIB rule that matches on 'tos 0x1c'. Instead, I was thinking of extending the IPv4 flow information structure with a new 'dscp_t' field (e.g., 'struct flowi4::dscp') and adding a new DSCP FIB rule attribute (e.g., 'FRA_DSCP') that accepts values in the range of [0, 63] which both address families will support. This will allow user space to get a consistent behavior between IPv4 and IPv6 with regards to DSCP matching, without affecting existing use cases. Adding the new field and initializing it correctly throughout the stack is not a small undertaking so I was wondering a) Are you OK with the suggested approach? b) If not, what else would you suggest? Thanks [1] https://lpc.events/event/11/contributions/943/attachments/901/1780/inet_tos_lpc2021.pdf . X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Wed, 26 Jun 2024 05:43:27 -0700 Message-ID: <0000000000006293f0061bca5cea@google.com> Subject: [syzbot] [net?] general protection fault in coalesce_fill_reply From: syzbot To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1259595 org.kernel.vger.netdev:355105 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hello, syzbot found the following issue on: HEAD commit: 50b70845fc5c Merge branch 'add-ethernet-driver-for-tehuti-.. git tree: net-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=1780b3b6980000 kernel config: https://syzkaller.appspot.com/x/.config?x=e78fc116033e0ab7 dashboard link: https://syzkaller.appspot.com/bug?extid=e77327e34cdc8c36b7d3 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1599901a980000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1429e301980000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/2c4a7dba390c/disk-50b70845.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/62ea7d7c8bc6/vmlinux-50b70845.xz kernel image: https://storage.googleapis.com/syzbot-assets/573c2ae03545/bzImage-50b70845.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e77327e34cdc8c36b7d3@syzkaller.appspotmail.com Oops: general protection fault, probably for non-canonical address 0xdffffc0000000193: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000c98-0x0000000000000c9f] CPU: 1 PID: 5093 Comm: syz-executor403 Not tainted 6.10.0-rc4-syzkaller-00936-g50b70845fc5c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:coalesce_fill_reply+0xcc/0x1b70 net/ethtool/coalesce.c:214 Code: e8 19 2c f9 f7 4c 89 f0 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 f7 e8 e3 f1 5e f8 bb 98 0c 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 c5 f1 5e f8 48 8b 03 48 89 44 24 RSP: 0018:ffffc90003526ee0 EFLAGS: 00010206 RAX: 0000000000000193 RBX: 0000000000000c98 RCX: ffff88802661da00 RDX: 0000000000000000 RSI: ffff88801b72e740 RDI: ffff88802dac6780 RBP: ffffc90003527118 R08: ffffffff899bb137 R09: 1ffff11003e8b805 R10: dffffc0000000000 R11: ffffffff899cf860 R12: ffffffff899cf860 R13: dffffc0000000000 R14: ffff88801b72e740 R15: ffff88802dac6780 FS: 000055557bf45380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200f9018 CR3: 0000000066db0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ethnl_default_dump_one net/ethtool/netlink.c:467 [inline] ethnl_default_dumpit+0x5ac/0xb30 net/ethtool/netlink.c:494 genl_dumpit+0x107/0x1a0 net/netlink/genetlink.c:1027 netlink_dump+0x647/0xd80 net/netlink/af_netlink.c:2325 __netlink_dump_start+0x59f/0x780 net/netlink/af_netlink.c:2440 genl_family_rcv_msg_dumpit net/netlink/genetlink.c:1076 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1192 [inline] genl_rcv_msg+0x88c/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f0/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2585 ___sys_sendmsg net/socket.c:2639 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2668 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f99a46ff219 Code: 48 83 c4 28 c3 e8 e7 18 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff97ad8a78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fff97ad8c48 RCX: 00007f99a46ff219 RDX: 0000000000000000 RSI: 0000000020000e80 RDI: 0000000000000003 RBP: 00007f99a4771610 R08: 0000000000000000 R09: 00007fff97ad8c48 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff97ad8c38 R14: 0000000000000001 R15: 0000000000000001 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:coalesce_fill_reply+0xcc/0x1b70 net/ethtool/coalesce.c:214 Code: e8 19 2c f9 f7 4c 89 f0 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 f7 e8 e3 f1 5e f8 bb 98 0c 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 c5 f1 5e f8 48 8b 03 48 89 44 24 RSP: 0018:ffffc90003526ee0 EFLAGS: 00010206 RAX: 0000000000000193 RBX: 0000000000000c98 RCX: ffff88802661da00 RDX: 0000000000000000 RSI: ffff88801b72e740 RDI: ffff88802dac6780 RBP: ffffc90003527118 R08: ffffffff899bb137 R09: 1ffff11003e8b805 R10: dffffc0000000000 R11: ffffffff899cf860 R12: ffffffff899cf860 R13: dffffc0000000000 R14: ffff88801b72e740 R15: ffff88802dac6780 FS: 000055557bf45380(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a18cbf60a8 CR3: 0000000066db0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: e8 19 2c f9 f7 call 0xf7f92c1e 5: 4c 89 f0 mov %r14,%rax 8: 48 c1 e8 03 shr $0x3,%rax c: 42 80 3c 28 00 cmpb $0x0,(%rax,%r13,1) 11: 74 08 je 0x1b 13: 4c 89 f7 mov %r14,%rdi 16: e8 e3 f1 5e f8 call 0xf85ef1fe 1b: bb 98 0c 00 00 mov $0xc98,%ebx 20: 49 03 1e add (%r14),%rbx 23: 48 89 d8 mov %rbx,%rax 26: 48 c1 e8 03 shr $0x3,%rax * 2a: 42 80 3c 28 00 cmpb $0x0,(%rax,%r13,1) <-- trapping instruction 2f: 74 08 je 0x39 31: 48 89 df mov %rbx,%rdi 34: e8 c5 f1 5e f8 call 0xf85ef1fe 39: 48 8b 03 mov (%rbx),%rax 3c: 48 rex.W 3d: 89 .byte 0x89 3e: 44 rex.R 3f: 24 .byte 0x24 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup . From: Jay Vosburgh To: Hangbin Liu cc: netdev@vger.kernel.org, Andy Gospodarek , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Ido Schimmel , Jiri Pirko , Amit Cohen , Nikolay Aleksandrov Subject: Re: [PATCHv3 net-next] bonding: 3ad: send ifinfo notify when mux state changed In-reply-to: <20240626075156.2565966-1-liuhangbin@gmail.com> References: <20240626075156.2565966-1-liuhangbin@gmail.com> Comments: In-reply-to Hangbin Liu message dated "Wed, 26 Jun 2024 15:51:56 +0800." X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2024 08:30:04 -0700 Message-ID: <1413993.1719415804@famine> Xref: photonic.trudheim.com org.kernel.vger.netdev:355115 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hangbin Liu wrote: >Currently, administrators need to retrieve LACP mux state changes from >the kernel DEBUG log using netdev_dbg and slave_dbg macros. To simplify >this process, let's send the ifinfo notification whenever the mux state >changes. This will enable users to directly access and monitor this >information using the ip monitor command. > >Signed-off-by: Hangbin Liu >--- >v3: forgot to use GFP_ATOMIC. (Nikolay Aleksandrov) > export symbol for rtmsg_ifinfo. It's weird that my build succeed with > tools/testing/selftests/drivers/net/bonding/config without export > the symbol, but build failed with tools/testing/selftests/net/config. I would hazard to guess that bonding/config works without export because it has CONFIG_BONDING=3Dy which builds bonding into the main image (not as a module), which wouldn't need the EXPORT_SYMBOL. I think the change is fine, the only question is whether it's better to have a wrapper for rtmsg_ifinfo() in net/core/dev.c (where all current callers are). I don't see a particular need, but others might want some consistency. Acked-by: Jay Vosburgh -J >v2: don't use call_netdevice_notifiers as it will case sleeping in atomic > context (Nikolay Aleksandrov) > >After this patch, we can see the following info with `ip -d monitor link` > >7: veth1@if6: mtu 1500 qdisc noqu= eue master bond0 state UP group default > link/ether 02:0a:04:c2:d6:21 brd ff:ff:ff:ff:ff:ff link-netns b promi= scuity 0 allmulti 0 minmtu 68 maxmtu 65535 > veth > bond_slave state BACKUP mii_status UP ... ad_aggregator_id 1 ad_actor= _oper_port_state 143 ad_actor_oper_port_state_str ad_partner_oper_port_state 55 ad_partner_oper_p= ort_state_str .= .. >7: veth1@if6: mtu 1500 qdisc noqu= eue master bond0 state UP group default > link/ether 02:0a:04:c2:d6:21 brd ff:ff:ff:ff:ff:ff link-netns b promi= scuity 0 allmulti 0 minmtu 68 maxmtu 65535 > veth > bond_slave state ACTIVE mii_status UP ... ad_aggregator_id 1 ad_actor= _oper_port_state 79 ad_actor_oper_port_state_str ad_partner_oper_port_state 1 ad_partner_oper_p= ort_state_str ... >7: veth1@if6: mtu 1500 qdisc noqu= eue master bond0 state UP group default > link/ether 02:0a:04:c2:d6:21 brd ff:ff:ff:ff:ff:ff link-netns b promi= scuity 0 allmulti 0 minmtu 68 maxmtu 65535 > veth > bond_slave state ACTIVE mii_status UP ... ad_aggregator_id 1 ad_actor= _oper_port_state 63 ad_actor_oper_port_state_str ad_partner_oper_port_state 63 ad= _partner_oper_port_state_str ... >--- > drivers/net/bonding/bond_3ad.c | 3 +++ > net/core/rtnetlink.c | 1 + > 2 files changed, 4 insertions(+) > >diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3a= d.c >index c6807e473ab7..b57c5670b31a 100644 >--- a/drivers/net/bonding/bond_3ad.c >+++ b/drivers/net/bonding/bond_3ad.c >@@ -11,6 +11,7 @@ > #include > #include > #include >+#include > #include > #include > #include >@@ -1185,6 +1186,8 @@ static void ad_mux_machine(struct port *port, bool = *update_slave_arr) > default: > break; > } >+ >+ rtmsg_ifinfo(RTM_NEWLINK, port->slave->dev, 0, GFP_ATOMIC, 0, NULL); > } > } > = >diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c >index eabfc8290f5e..4507bb8d5264 100644 >--- a/net/core/rtnetlink.c >+++ b/net/core/rtnetlink.c >@@ -4116,6 +4116,7 @@ void rtmsg_ifinfo(int type, struct net_device *dev,= unsigned int change, > rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags, > NULL, 0, portid, nlh); > } >+EXPORT_SYMBOL(rtmsg_ifinfo); > = > void rtmsg_ifinfo_newnet(int type, struct net_device *dev, unsigned int = change, > gfp_t flags, int *new_nsid, int new_ifindex) >-- = >2.45.0 > --- -Jay Vosburgh, jay.vosburgh@canonical.com . From: Michael Chan To: davem@davemloft.net Cc: netdev@vger.kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, pavan.chebbi@broadcom.com, andrew.gospodarek@broadcom.com, richardcochran@gmail.com Subject: [PATCH net-next 00/10] bnxt_en: PTP updates for net-next Date: Wed, 26 Jun 2024 09:42:57 -0700 Message-ID: <20240626164307.219568-1-michael.chan@broadcom.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000fe5938061bcdb6fc" Xref: photonic.trudheim.com org.kernel.vger.netdev:355117 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail --000000000000fe5938061bcdb6fc Content-Transfer-Encoding: 8bit The first 5 patches implement the PTP feature on the new BCM5760X chips. The main new hardware feature is the new TX timestamp completion which enables the driver to retrieve the TX timestamp in NAPI without deferring to the PTP worker. The last 5 patches increase the number of TX PTP packets in-flight from 1 to 4 on the older BCM5750X chips. On these older chips, we need to call firmware in the PTP worker to retrieve the timestamp. We use an arry to keep track of the in-flight TX PTP packets. Michael Chan (4): bnxt_en: Add new TX timestamp completion definitions bnxt_en: Add is_ts_pkt field to struct bnxt_sw_tx_bd bnxt_en: Allow some TX packets to be unprocessed in NAPI bnxt_en: Add TX timestamp completion logic Pavan Chebbi (6): bnxt_en: Add BCM5760X specific PHC registers mapping bnxt_en: Refactor all PTP TX timestamp fields into a struct bnxt_en: Remove an impossible condition check for PTP TX pending SKB bnxt_en: Let bnxt_stamp_tx_skb() return error code bnxt_en: Increase the max total outstanding PTP TX packets to 4 bnxt_en: Remove atomic operations on ptp->tx_avail drivers/net/ethernet/broadcom/bnxt/bnxt.c | 109 ++++++++----- drivers/net/ethernet/broadcom/bnxt/bnxt.h | 42 ++++- drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 151 +++++++++++++----- drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h | 36 ++++- 4 files changed, 254 insertions(+), 84 deletions(-) -- 2.30.1 --000000000000fe5938061bcdb6fc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQbQYJKoZIhvcNAQcCoIIQXjCCEFoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3EMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBUwwggQ0oAMCAQICDF5AaMOe0cZvaJpCQjANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAwODIxMzhaFw0yNTA5MTAwODIxMzhaMIGO MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFTATBgNVBAMTDE1pY2hhZWwgQ2hhbjEoMCYGCSqGSIb3DQEJ ARYZbWljaGFlbC5jaGFuQGJyb2FkY29tLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALhEmG7egFWvPKcrDxuNhNcn2oHauIHc8AzGhPyJxU4S6ZUjHM/psoNo5XxlMSRpYE7g7vLx J4NBefU36XTEWVzbEkAuOSuJTuJkm98JE3+wjeO+aQTbNF3mG2iAe0AZbAWyqFxZulWitE8U2tIC 9mttDjSN/wbltcwuti7P57RuR+WyZstDlPJqUMm1rJTbgDqkF2pnvufc4US2iexnfjGopunLvioc OnaLEot1MoQO7BIe5S9H4AcCEXXcrJJiAtMCl47ARpyHmvQFQFFTrHgUYEd9V+9bOzY7MBIGSV1N /JfsT1sZw6HT0lJkSQefhPGpBniAob62DJP3qr11tu8CAwEAAaOCAdowggHWMA4GA1UdDwEB/wQE AwIFoDCBowYIKwYBBQUHAQEEgZYwgZMwTgYIKwYBBQUHMAKGQmh0dHA6Ly9zZWN1cmUuZ2xvYmFs c2lnbi5jb20vY2FjZXJ0L2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwLmNydDBBBggrBgEFBQcw AYY1aHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAw TQYDVR0gBEYwRDBCBgorBgEEAaAyASgKMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2Jh bHNpZ24uY29tL3JlcG9zaXRvcnkvMAkGA1UdEwQCMAAwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDov L2NybC5nbG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcmwwJAYDVR0R BB0wG4EZbWljaGFlbC5jaGFuQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNV HSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQU31rAyTdZweIF0tJTFYwfOv2w L4QwDQYJKoZIhvcNAQELBQADggEBACcuyaGmk0NSZ7Kio7O7WSZ0j0f9xXcBnLbJvQXFYM7JI5uS kw5ozATEN5gfmNIe0AHzqwoYjAf3x8Dv2w7HgyrxWdpjTKQFv5jojxa3A5LVuM8mhPGZfR/L5jSk 5xc3llsKqrWI4ov4JyW79p0E99gfPA6Waixoavxvv1CZBQ4Stu7N660kTu9sJrACf20E+hdKLoiU hd5wiQXo9B2ncm5P3jFLYLBmPltIn/uzdiYpFj+E9kS9XYDd+boBZhN1Vh0296zLQZobLfKFzClo E6IFyTTANonrXvCRgodKS+QJEH8Syu2jSKe023aVemkuZjzvPK7o9iU7BKkPG2pzLPgxggJtMIIC aQIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQD EyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgxeQGjDntHGb2iaQkIw DQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIEQ0khCK+kb/1J4k/5sUf3DwxhcLdmTL k2hY9jRABEz2MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI0MDYy NjE2NDMzMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQC ATANBgkqhkiG9w0BAQEFAASCAQBmNwIAoSQCk/9anBIHQE0YHIF2MpLaPta9+XP0oWBDmIgvBVCA tY05fxiZSFrd94fOP9ct66Z4ACiFsOL+tKOdZ21NLiwMLV8/S/DwZovZ45qn3q2B5+/lhgXyCf3A 7916u6yCqXBCUYIYQb3TaxTJ2KOc45NpOzzL8DtgrL50t0SITKfUroBfYK2Q/rLnBx4UyDp9wiLc b5yHAzvh6tUtdzCtN9VgoMtDOx1b+QWg0Rh+DUGgaLjhsifl+BR5IBb5ILRw4xCLxQwzvjE1daSf 3Q/C9ePEnqBOXtxbAEDaFvSv6GY7STsWNfte2nHlwnXtbsjTCmayIytj68rdGCY3 --000000000000fe5938061bcdb6fc-- . From: Jakub Sitnicki Subject: [PATCH net-next v2 0/2] Lift UDP_SEGMENT restriction for egress via device w/o csum offload Date: Wed, 26 Jun 2024 19:51:25 +0200 Message-Id: <20240626-linux-udpgso-v2-0-422dfcbd6b48@cloudflare.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com Xref: photonic.trudheim.com org.kernel.vger.netdev:355131 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail This is a follow-up to an earlier question [1] if we can make UDP GSO work with any egress device, even those with no checksum offload capability. That's the default setup for TUN/TAP. Because there is a change in behavior - sendmsg() does no longer return EIO error - I'm submitting through net-next tree, rather than net, as per Willem's advice. [1] https://lore.kernel.org/netdev/87jzqsld6q.fsf@cloudflare.com/ To: netdev@vger.kernel.org Cc: David S. Miller Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Willem de Bruijn Cc: kernel-team@cloudflare.com Signed-off-by: Jakub Sitnicki Changes in v2: - Fixup ip link arguments order (Jakub) - Describe performance impact compared to regular sendmsg (Willem) - Link to v1: https://lore.kernel.org/r/20240622-linux-udpgso-v1-0-d2344157ab2a@cloudflare.com --- Jakub Sitnicki (2): udp: Allow GSO transmit from devices with no checksum offload selftests/net: Add test coverage for UDP GSO software fallback net/ipv4/udp.c | 3 +-- net/ipv4/udp_offload.c | 8 +++++++ net/ipv6/udp.c | 3 +-- tools/testing/selftests/net/udpgso.c | 15 +++++++++--- tools/testing/selftests/net/udpgso.sh | 43 +++++++++++++++++++++++++++++++++++ 5 files changed, 65 insertions(+), 7 deletions(-) . From: zijianzhang@bytedance.com To: netdev@vger.kernel.org Cc: edumazet@google.com, willemdebruijn.kernel@gmail.com, cong.wang@bytedance.com, xiaochun.lu@bytedance.com, Zijian Zhang Subject: [PATCH net-next v6 0/4] net: A lightweight zero-copy notification Date: Wed, 26 Jun 2024 19:33:59 +0000 Message-Id: <20240626193403.3854451-1-zijianzhang@bytedance.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.netdev:355137 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Zijian Zhang Original title is "net: socket sendmsg MSG_ZEROCOPY_UARG". Original notification mechanism needs poll + recvmmsg which is not easy for applcations to accommodate. And, it also incurs unignorable overhead including extra system calls and usage of socket optmem. While making maximum reuse of the existing MSG_ZEROCOPY related code, this patch set introduces a new zerocopy socket notification mechanism. Users of sendmsg pass a control message as a placeholder for the incoming notifications. Upon returning, kernel embeds notifications directly into user arguments passed in. By doing so, we can significantly reduce the complexity and overhead for managing notifications. In an ideal pattern, the user will keep calling sendmsg with SCM_ZC_NOTIFICATION msg_control, and the notification will be delivered as soon as possible. Users need to pass in a user space address pointing to an array of struct zc_info_elem, and the cmsg_len should be the memory size of the array instead of the size of the pointer itself. As Willem commented, > The main design issue with this series is this indirection, rather > than passing the array of notifications as cmsg. > This trick circumvents having to deal with compat issues and having to > figure out copy_to_user in ____sys_sendmsg (as msg_control is an > in-kernel copy). > This is quite hacky, from an API design PoV. > As is passing a pointer, but expecting msg_controllen to hold the > length not of the pointer, but of the pointed to user buffer. > I had also hoped for more significant savings. Especially with the > higher syscall overhead due to meltdown and spectre mitigations vs > when MSG_ZEROCOPY was introduced and I last tried this optimization. We solve it by supporting put_cmsg to userspace in TX path in v5. Changelog: v1 -> v2: - Reuse errormsg queue in the new notification mechanism, users can actually use these two mechanisms in hybrid way if they want to do so. - Update case SCM_ZC_NOTIFICATION in __sock_cmsg_send 1. Regardless of 32-bit, 64-bit program, we will always handle u64 type user address. 2. The size of data to copy_to_user is precisely calculated in case of kernel stack leak. - fix (kbuild-bot) 1. Add SCM_ZC_NOTIFICATION to arch-specific header files. 2. header file types.h in include/uapi/linux/socket.h v2 -> v3: - 1. Users can now pass in the address of the zc_info_elem directly with appropriate cmsg_len instead of the ugly user interface. Plus, the handler is now compatible with MSG_CMSG_COMPAT and 32-bit pointer. - 2. Suggested by Willem, another strategy of getting zc info is briefly taking the lock of sk_error_queue and move to a private list, like net_rx_action. I thought sk_error_queue is protected by sock_lock, so that it's impossible for the handling of zc info and users recvmsg from the sk_error_queue at the same time. However, sk_error_queue is protected by its own lock. I am afraid that during the time it is handling the private list, users may fail to get other error messages in the queue via recvmsg. Thus, I don't implement the splice logic in this version. Any comments? v3 -> v4: - 1. Change SOCK_ZC_INFO_MAX to 64 to avoid large stack frame size. - 2. Fix minor typos. - 3. Change cfg_zerocopy from int to enum in msg_zerocopy.c v4 -> v5: - 1. Passing user address directly to kernel raises concerns about ABI. In this version, we support put_cmsg to userspace in TX path to solve this problem. v5 -> v6: - 1. Cleanly copy cmsg to user upon returning of ___sys_sendmsg * Performance I extend the selftests/msg_zerocopy.c to accommodate the new mechanism, test result is as follows, cfg_notification_limit = 1, in this case the original method approximately aligns with the semantics of new one. In this case, the new flag has around 13% cpu savings in TCP and 18% cpu savings in UDP. +---------------------+---------+---------+---------+---------+ | Test Type / Protocol| TCP v4 | TCP v6 | UDP v4 | UDP v6 | +---------------------+---------+---------+---------+---------+ | ZCopy (MB) | 5147 | 4885 | 7489 | 7854 | +---------------------+---------+---------+---------+---------+ | New ZCopy (MB) | 5859 | 5505 | 9053 | 9236 | +---------------------+---------+---------+---------+---------+ | New ZCopy / ZCopy | 113.83% | 112.69% | 120.88% | 117.59% | +---------------------+---------+---------+---------+---------+ cfg_notification_limit = 32, the new mechanism performs 8% better in TCP. For UDP, no obvious performance gain is observed and sometimes may lead to degradation. Thus, if users don't need to retrieve the notification ASAP in UDP, the original mechanism is preferred. +---------------------+---------+---------+---------+---------+ | Test Type / Protocol| TCP v4 | TCP v6 | UDP v4 | UDP v6 | +---------------------+---------+---------+---------+---------+ | ZCopy (MB) | 6272 | 6138 | 12138 | 10055 | +---------------------+---------+---------+---------+---------+ | New ZCopy (MB) | 6774 | 6620 | 11504 | 10355 | +---------------------+---------+---------+---------+---------+ | New ZCopy / ZCopy | 108.00% | 107.85% | 94.78% | 102.98% | +---------------------+---------+---------+---------+---------+ Zijian Zhang (4): selftests: fix OOM problem in msg_zerocopy selftest sock: support copy cmsg to userspace in TX path sock: add MSG_ZEROCOPY notification mechanism based on msg_control selftests: add MSG_ZEROCOPY msg_control notification test arch/alpha/include/uapi/asm/socket.h | 2 + arch/mips/include/uapi/asm/socket.h | 2 + arch/parisc/include/uapi/asm/socket.h | 2 + arch/sparc/include/uapi/asm/socket.h | 2 + include/linux/socket.h | 6 + include/uapi/asm-generic/socket.h | 2 + include/uapi/linux/socket.h | 10 ++ net/core/sock.c | 44 ++++++++ net/ipv4/ip_sockglue.c | 2 + net/ipv6/datagram.c | 3 + net/socket.c | 45 ++++++++ tools/testing/selftests/net/msg_zerocopy.c | 117 ++++++++++++++++++-- tools/testing/selftests/net/msg_zerocopy.sh | 1 + 13 files changed, 231 insertions(+), 7 deletions(-) -- 2.20.1 .