From: Kuniyuki Iwashima To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni CC: David Ahern , Dmitry Safonov <0x7f454c46@gmail.com>, Kuniyuki Iwashima , Kuniyuki Iwashima , Subject: [PATCH v1 net] tcp: Don't flag tcp_sk(sk)->rx_opt.saw_unknown for TCP AO. Date: Tue, 2 Jul 2024 20:35:08 -0700 Message-ID: <20240703033508.6321-1-kuniyu@amazon.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.netdev:355507 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail When we process segments with TCP AO, we don't check it in tcp_parse_options(). Thus, opt_rx->saw_unknown is set to 1, which unconditionally triggers the BPF TCP option parser. Let's avoid the unnecessary BPF invocation. Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments") Signed-off-by: Kuniyuki Iwashima --- net/ipv4/tcp_input.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index e67cbeeeb95b..77294fd5fd3e 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4223,6 +4223,13 @@ void tcp_parse_options(const struct net *net, * checked (see tcp_v{4,6}_rcv()). */ break; +#endif +#ifdef CONFIG_TCP_AO + case TCPOPT_AO: + /* TCP AO has already been checked + * (see tcp_inbound_ao_hash()). + */ + break; #endif case TCPOPT_FASTOPEN: tcp_parse_fastopen_option( -- 2.30.2 . From: Daniel Borkmann To: kuba@kernel.org Cc: netdev@vger.kernel.org, linux-nfs@vger.kernel.org, Daniel Borkmann , Lex Siegel , Neil Brown , Trond Myklebust , Anna Schumaker Subject: [PATCH net v3] net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket Date: Wed, 3 Jul 2024 09:01:20 +0200 Message-ID: <20240703070120.0cTO8sZ33tAo2CoVHbOPcnkOLwOpqf4JIU_xR9c3Lfo@z> 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:355511 Newsgroups: org.kernel.vger.netdev 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 Cc: Trond Myklebust Cc: Anna Schumaker 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. ] v1 -> v2 -> v3: - Plain resend, adding correct sunrpc folks to Cc https://lore.kernel.org/bpf/Zn7wtStV+iafWRXj@tissot.1015granger.net/ 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: Shay Drory To: , , , , , , CC: , , , , , Shay Drory Subject: [PATCH net-next v9 0/2] Introduce auxiliary bus IRQs sysfs Date: Wed, 3 Jul 2024 10:38:56 +0300 Message-ID: <20240703073858.932299-1-shayd@nvidia.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.netdev:355513 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.linux-rdma Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Today, PCI PFs and VFs, which are anchored on the PCI bus, display their IRQ information in the /msi_irqs/ sysfs files. PCI subfunctions (SFs) are similar to PFs and VFs and these SFs are anchored on the auxiliary bus. However, these PCI SFs lack such IRQ information on the auxiliary bus, leaving users without visibility into which IRQs are used by the SFs. This absence makes it impossible to debug situations and to understand the source of interrupts/SFs for performance tuning and debug. Additionally, the SFs are multifunctional devices supporting RDMA, network devices, clocks, and more, similar to their peer PCI PFs and VFs. Therefore, it is desirable to have SFs' IRQ information available at the bus/device level. To overcome the above limitations, this short series extends the auxiliary bus to display IRQ information in sysfs, similar to that of PFs and VFs. It adds an 'irqs' directory under the auxiliary device and includes an sysfs file within it. For example: $ ls /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/ 50 51 52 53 54 55 56 57 58 Patch summary: ============== patch-1 adds auxiliary bus to support irqs used by auxiliary device patch-2 mlx5 driver using exposing irqs for PCI SF devices via auxiliary bus --- v8-v9: - add Przemek RB - use guard() in auxiliary_irq_dir_prepare (Paolo) v7-v8: - use cleanup.h for info and name fields (Greg) - correct error flow in auxiliary_irq_dir_prepare (Przemek) - add documentation for new fields of auxiliary_device (Simon) v6->v7: - dynamically creating irqs directory when first irq file created, patch #1 (Greg). - removed irqs flag and simplified the dev_add() API, patch #1 (Greg). - move sysfs related new code to a new auxiliary_sysfs.c file, patch #1 (Greg). v5->v6: - fix error flow in patch #2 (Przemek and Parav). - remove concept of shared and exclusive and hence global xarray in patch #1 (Greg). v4->v5: - addressed comments from Greg in patch #1. v3->4: - addressed comments from Przemek in patch #1. v2->v3: - addressed comments from Parav and Przemek in patch #1. - fixed a bug in patch #2. v1->v2: - addressed comments from Greg, Simon H and kernel test boot in patch #1. Shay Drory (2): driver core: auxiliary bus: show auxiliary device IRQs net/mlx5: Expose SFs IRQs Documentation/ABI/testing/sysfs-bus-auxiliary | 9 ++ drivers/base/Makefile | 1 + drivers/base/auxiliary.c | 1 + drivers/base/auxiliary_sysfs.c | 111 ++++++++++++++++++ drivers/net/ethernet/mellanox/mlx5/core/eq.c | 6 +- .../mellanox/mlx5/core/irq_affinity.c | 18 ++- .../ethernet/mellanox/mlx5/core/mlx5_core.h | 6 + .../ethernet/mellanox/mlx5/core/mlx5_irq.h | 12 +- .../net/ethernet/mellanox/mlx5/core/pci_irq.c | 12 +- include/linux/auxiliary_bus.h | 22 ++++ 10 files changed, 187 insertions(+), 11 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-auxiliary create mode 100644 drivers/base/auxiliary_sysfs.c -- 2.38.1 . X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Wed, 03 Jul 2024 02:56:23 -0700 Message-ID: <000000000000ce42b9061c54d76a@google.com> Subject: [syzbot] [wireless?] WARNING in rate_control_rate_init (3) From: syzbot To: davem@davemloft.net, edumazet@google.com, johannes@sipsolutions.net, kuba@kernel.org, linux-kernel@vger.kernel.org, linux-wireless@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:1266296 org.kernel.vger.linux-wireless:85619 org.kernel.vger.netdev:355519 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hello, syzbot found the following issue on: HEAD commit: ac26327635d6 Merge branch 'fixes-for-stm32-dwmac-driver-fa.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=17b17ab9980000 kernel config: https://syzkaller.appspot.com/x/.config?x=5264b58fdff6e881 dashboard link: https://syzkaller.appspot.com/bug?extid=9bdc0c5998ab45b05030 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/192a90a6425b/disk-ac263276.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/233fc7270a4e/vmlinux-ac263276.xz kernel image: https://storage.googleapis.com/syzbot-assets/585e26cc8536/bzImage-ac263276.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9bdc0c5998ab45b05030@syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 1 PID: 8730 at net/mac80211/rate.c:48 rate_control_rate_init+0x588/0x5f0 net/mac80211/rate.c:48 Modules linked in: CPU: 1 PID: 8730 Comm: syz.0.1096 Not tainted 6.10.0-rc5-syzkaller-01193-gac26327635d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:rate_control_rate_init+0x588/0x5f0 net/mac80211/rate.c:48 Code: 00 00 00 e8 4a 75 01 f7 f0 41 80 8d 82 01 00 00 20 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 69 ad 9b f6 90 <0f> 0b 90 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d eb 65 89 e9 80 RSP: 0018:ffffc90004717058 EFLAGS: 00010283 RAX: ffffffff8afa79b7 RBX: ffff88802deceb98 RCX: 0000000000040000 RDX: ffffc90009d89000 RSI: 0000000000001518 RDI: 0000000000001519 RBP: 0000000000000001 R08: ffffffff8afa7622 R09: 1ffffffff25f78b0 R10: dffffc0000000000 R11: fffffbfff25f78b1 R12: ffff88802e488e20 R13: ffff88802a9c8000 R14: 1ffff1100553900a R15: 0000000000000000 FS: 00007f7083c2e6c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7082d5b420 CR3: 000000002df6e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sta_apply_auth_flags+0x1b6/0x410 net/mac80211/cfg.c:1711 sta_apply_parameters+0xe23/0x1550 net/mac80211/cfg.c:2061 ieee80211_add_station+0x3da/0x630 net/mac80211/cfg.c:2127 rdev_add_station+0x11b/0x2b0 net/wireless/rdev-ops.h:201 nl80211_new_station+0x1d53/0x2550 net/wireless/nl80211.c:7683 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/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:0x7f7082d75b99 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7083c2e048 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7082f03f60 RCX: 00007f7082d75b99 RDX: 0000000000000000 RSI: 0000000020001080 RDI: 0000000000000003 RBP: 00007f7082de4a7a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f7082f03f60 R15: 00007fff740d84f8 --- 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 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 . Message-ID: <4886830b-73fe-47f5-9635-0f3910c8e205@intel.com> Date: Wed, 3 Jul 2024 12:13:58 +0200 From: Przemek Kitszel Content-Language: en-US To: Jakub Kicinski , Jiri Pirko CC: "netdev@vger.kernel.org" Subject: [RFC net-next] generate boilerplate impls such as devlink_resource_register() Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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:355522 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi, I have and idea that boilerplate devlink_ wrappers over devl_ functions could be generated via short script, with the handcrafted .c code as the only input. Take for example the following [one line] added to devlink/resource.c would replace the whole definition and kdoc, which would be placed in the generated file in about the same form as the current code. This will be applied to all suitable functions of course. The script will be short, but not so trivial to write it without prior RFC. For those wondering if I don't have better things to do: yes, but I have also some awk-time that will not be otherwise spend on more serious stuff anyway :) [one line] DEVLINK_GEN_SYMBOL_GPL(devlink_resource_register); [removed part below] /** * devlink_resource_register - devlink resource register * * @devlink: devlink * @resource_name: resource's name * @resource_size: resource's size * @resource_id: resource's id * @parent_resource_id: resource's parent id * @size_params: size parameters * * Generic resources should reuse the same names across drivers. * Please see the generic resources list at: * Documentation/networking/devlink/devlink-resource.rst * * Context: Takes and release devlink->lock . */ int devlink_resource_register(struct devlink *devlink, const char *resource_name, u64 resource_size, u64 resource_id, u64 parent_resource_id, const struct devlink_resource_size_params *size_params) { int err; devl_lock(devlink); err = devl_resource_register(devlink, resource_name, resource_size, resource_id, parent_resource_id, size_params); devl_unlock(devlink); return err; } EXPORT_SYMBOL_GPL(devlink_resource_register); . From: =?UTF-8?q?Asbj=C3=B8rn=20Sloth=20T=C3=B8nnesen?= To: netdev@vger.kernel.org Cc: =?UTF-8?q?Asbj=C3=B8rn=20Sloth=20T=C3=B8nnesen?= , Davide Caratti , Ilya Maximets , Jamal Hadi Salim , Cong Wang , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Simon Horman , Ratheesh Kannoth , Florian Westphal , Alexander Lobakin , linux-kernel@vger.kernel.org Subject: [PATCH net-next 0/9] flower: rework TCA_FLOWER_KEY_ENC_FLAGS usage Date: Wed, 3 Jul 2024 10:45:49 +0000 Message-ID: <20240703104600.455125-1-ast@fiberby.net> 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: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1266411 org.kernel.vger.netdev:355525 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail This series reworks the recently added TCA_FLOWER_KEY_ENC_FLAGS attribute, to be more like TCA_FLOWER_KEY_FLAGS, and use the unused u32 flags field in FLOW_DISSECTOR_KEY_ENC_CONTROL, instead of adding a new flags field as FLOW_DISSECTOR_KEY_ENC_FLAGS. I have defined the new FLOW_DIS_F_* and TCA_FLOWER_KEY_FLAGS_* flags to co-exist with the existing flags, so the meaning of the flags field in struct flow_dissector_key_control is not depending on the context it is used in. If we run out of bits then we can always split them up later, if we really want to. Future flags might also be valid in both contexts. iproute2 RFC patch: https://lore.kernel.org/897379f1850a50d8c320ca3facd06c5f03943bac.1719506876.git.dcaratti@redhat.com/ --- Changelog: v1: - Change netlink attribute type from NLA_U32 to NLA_BE32. - Ensure that the FLOW_DISSECTOR_KEY_ENC_CONTROL is also masked for non-IP. - Fix preexisting typo in kdoc for struct flow_dissector_key_control (all suggested by Davide) RFC: https://lore.kernel.org/20240611235355.177667-1-ast@fiberby.net/ Asbjørn Sloth Tønnesen (9): net/sched: flower: define new tunnel flags net/sched: cls_flower: prepare fl_{set,dump}_key_flags() for ENC_FLAGS net/sched: cls_flower: add policy for TCA_FLOWER_KEY_FLAGS flow_dissector: prepare for encapsulated control flags flow_dissector: set encapsulated control flags from tun_flags net/sched: cls_flower: add tunnel flags to fl_{set,dump}_key_flags() net/sched: cls_flower: rework TCA_FLOWER_KEY_ENC_FLAGS usage flow_dissector: cleanup FLOW_DISSECTOR_KEY_ENC_FLAGS flow_dissector: set encapsulation control flags for non-IP include/net/flow_dissector.h | 26 +++---- include/net/ip_tunnels.h | 12 --- include/uapi/linux/pkt_cls.h | 9 ++- net/core/flow_dissector.c | 50 ++++++------ net/sched/cls_flower.c | 142 ++++++++++++++++++++--------------- 5 files changed, 129 insertions(+), 110 deletions(-) -- 2.45.2 . From: Florian Westphal To: dev@openvswitch.org Cc: pshelar@ovn.org, netdev@vger.kernel.org, Florian Westphal Subject: [PATCH net-next] openvswitch: prepare for stolen verdict coming from conntrack and nat engine Date: Wed, 3 Jul 2024 12:46:34 +0200 Message-ID: <20240703104640.20878-1-fw@strlen.de> 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:355551 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail At this time, conntrack either returns NF_ACCEPT or NF_DROP. To improve debuging it would be nice to be able to replace NF_DROP verdict with NF_DROP_REASON() helper, This helper releases the skb instantly (so drop_monitor can pinpoint precise location) and returns NF_STOLEN. Prepare call sites to deal with this before introducing such changes in conntrack and nat core. Signed-off-by: Florian Westphal --- net/openvswitch/conntrack.c | 47 +++++++++++++++++++++++++++++-------- 1 file changed, 37 insertions(+), 10 deletions(-) diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c index 3b980bf2770b..8eb1d644b741 100644 --- a/net/openvswitch/conntrack.c +++ b/net/openvswitch/conntrack.c @@ -679,6 +679,8 @@ static int ovs_ct_nat(struct net *net, struct sw_flow_key *key, action |= BIT(NF_NAT_MANIP_DST); err = nf_ct_nat(skb, ct, ctinfo, &action, &info->range, info->commit); + if (err != NF_ACCEPT) + return err; if (action & BIT(NF_NAT_MANIP_SRC)) ovs_nat_update_key(key, skb, NF_NAT_MANIP_SRC); @@ -697,6 +699,22 @@ static int ovs_ct_nat(struct net *net, struct sw_flow_key *key, } #endif +static int verdict_to_errno(unsigned int verdict) +{ + switch (verdict & NF_VERDICT_MASK) { + case NF_ACCEPT: + return 0; + case NF_DROP: + return -EINVAL; + case NF_STOLEN: + return -EINPROGRESS; + default: + break; + } + + return -EINVAL; +} + /* Pass 'skb' through conntrack in 'net', using zone configured in 'info', if * not done already. Update key with new CT state after passing the packet * through conntrack. @@ -735,7 +753,7 @@ static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key, err = nf_conntrack_in(skb, &state); if (err != NF_ACCEPT) - return -ENOENT; + return verdict_to_errno(err); /* Clear CT state NAT flags to mark that we have not yet done * NAT after the nf_conntrack_in() call. We can actually clear @@ -762,9 +780,12 @@ static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key, * the key->ct_state. */ if (info->nat && !(key->ct_state & OVS_CS_F_NAT_MASK) && - (nf_ct_is_confirmed(ct) || info->commit) && - ovs_ct_nat(net, key, info, skb, ct, ctinfo) != NF_ACCEPT) { - return -EINVAL; + (nf_ct_is_confirmed(ct) || info->commit)) { + int err = ovs_ct_nat(net, key, info, skb, ct, ctinfo); + + err = verdict_to_errno(err); + if (err) + return err; } /* Userspace may decide to perform a ct lookup without a helper @@ -795,9 +816,12 @@ static int __ovs_ct_lookup(struct net *net, struct sw_flow_key *key, * - When committing an unconfirmed connection. */ if ((nf_ct_is_confirmed(ct) ? !cached || add_helper : - info->commit) && - nf_ct_helper(skb, ct, ctinfo, info->family) != NF_ACCEPT) { - return -EINVAL; + info->commit)) { + int err = nf_ct_helper(skb, ct, ctinfo, info->family); + + err = verdict_to_errno(err); + if (err) + return err; } if (nf_ct_protonum(ct) == IPPROTO_TCP && @@ -1001,10 +1025,9 @@ static int ovs_ct_commit(struct net *net, struct sw_flow_key *key, /* This will take care of sending queued events even if the connection * is already confirmed. */ - if (nf_conntrack_confirm(skb) != NF_ACCEPT) - return -EINVAL; + err = nf_conntrack_confirm(skb); - return 0; + return verdict_to_errno(err); } /* Returns 0 on success, -EINPROGRESS if 'skb' is stolen, or other nonzero @@ -1039,6 +1062,10 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb, else err = ovs_ct_lookup(net, key, info, skb); + /* conntrack core returned NF_STOLEN */ + if (err == -EINPROGRESS) + return err; + skb_push_rcsum(skb, nh_ofs); if (err) ovs_kfree_skb_reason(skb, OVS_DROP_CONNTRACK); -- 2.44.2 . From: Marcin Szycik To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com, Marcin Szycik , Michal Swiatkowski Subject: [PATCH iwl-next] ice: Fix field vector array data type Date: Wed, 3 Jul 2024 13:25:02 +0200 Message-ID: <20240703112502.28021-1-marcin.szycik@linux.intel.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:355555 Newsgroups: org.kernel.vger.netdev,org.osuosl.intel-wired-lan Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Correct the datatype of fv_idx array in struct ice_sw_recipe to be u8 instead of u16. This array contents are used solely to be later passed to lkup_indx in struct ice_aqc_recipe_content, which is u8. Fixes: 6d82b8eda4c7 ("ice: Optimize switch recipe creation") Reviewed-by: Michal Swiatkowski Signed-off-by: Marcin Szycik --- Targeting next, as the commit to be fixed is on dev-queue. Tony, please squash this with commit 6d82b8eda4c7 ("ice: Optimize switch recipe creation") --- drivers/net/ethernet/intel/ice/ice_switch.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h index 3e4af531b875..671d7a5f359f 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -226,7 +226,7 @@ struct ice_sw_recipe { */ struct ice_fv_word ext_words[ICE_MAX_CHAIN_WORDS]; u16 word_masks[ICE_MAX_CHAIN_WORDS]; - u16 fv_idx[ICE_MAX_CHAIN_WORDS]; + u8 fv_idx[ICE_MAX_CHAIN_WORDS]; u16 fv_mask[ICE_MAX_CHAIN_WORDS]; /* Bit map specifying the IDs associated with this group of recipe */ -- 2.45.0 . From: To: , , , CC: Edward Cree , , , Subject: [PATCH net-next] ethtool: move firmware flashing flag to struct ethtool_netdev_state Date: Wed, 3 Jul 2024 13:18:49 +0100 Message-ID: <20240703121849.652893-1-edward.cree@amd.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.netdev:355559 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Edward Cree Commit 31e0aa99dc02 ("ethtool: Veto some operations during firmware flashing process") added a flag module_fw_flash_in_progress to struct net_device. As this is ethtool related state, move it to the recently created struct ethtool_netdev_state, accessed via the 'ethtool' member of struct net_device. Suggested-by: Jakub Kicinski Signed-off-by: Edward Cree --- Build tested only. include/linux/ethtool.h | 2 ++ include/linux/netdevice.h | 3 --- net/ethtool/eeprom.c | 2 +- net/ethtool/ioctl.c | 8 ++++---- net/ethtool/module.c | 10 +++++----- net/ethtool/netlink.c | 2 +- 6 files changed, 13 insertions(+), 14 deletions(-) diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index f74bb0cf8ed1..3a99238ef895 100644 --- a/include/linux/ethtool.h +++ b/include/linux/ethtool.h @@ -1107,11 +1107,13 @@ int ethtool_virtdev_set_link_ksettings(struct net_device *dev, * @rss_lock: Protects entries in @rss_ctx. May be taken from * within RTNL. * @wol_enabled: Wake-on-LAN is enabled + * @module_fw_flash_in_progress: Module firmware flashing is in progress. */ struct ethtool_netdev_state { struct xarray rss_ctx; struct mutex rss_lock; unsigned wol_enabled:1; + unsigned module_fw_flash_in_progress:1; }; struct phy_device; diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 3c719f0d5f5a..93558645c6d0 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -1989,8 +1989,6 @@ enum netdev_reg_state { * * @threaded: napi threaded mode is enabled * - * @module_fw_flash_in_progress: Module firmware flashing is in progress. - * * @net_notifier_list: List of per-net netdev notifier block * that follow this device when it is moved * to another network namespace. @@ -2376,7 +2374,6 @@ struct net_device { bool proto_down; bool threaded; - unsigned module_fw_flash_in_progress:1; struct list_head net_notifier_list; #if IS_ENABLED(CONFIG_MACSEC) diff --git a/net/ethtool/eeprom.c b/net/ethtool/eeprom.c index f36811b3ecf1..3b8209e930fd 100644 --- a/net/ethtool/eeprom.c +++ b/net/ethtool/eeprom.c @@ -91,7 +91,7 @@ static int get_module_eeprom_by_page(struct net_device *dev, { const struct ethtool_ops *ops = dev->ethtool_ops; - if (dev->module_fw_flash_in_progress) { + if (dev->ethtool->module_fw_flash_in_progress) { NL_SET_ERR_MSG(extack, "Module firmware flashing is in progress"); return -EBUSY; diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index d8795ed07ba3..ee4ecedd92fc 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -658,7 +658,7 @@ static int ethtool_get_settings(struct net_device *dev, void __user *useraddr) if (!dev->ethtool_ops->get_link_ksettings) return -EOPNOTSUPP; - if (dev->module_fw_flash_in_progress) + if (dev->ethtool->module_fw_flash_in_progress) return -EBUSY; memset(&link_ksettings, 0, sizeof(link_ksettings)); @@ -1572,7 +1572,7 @@ static int ethtool_reset(struct net_device *dev, char __user *useraddr) if (!dev->ethtool_ops->reset) return -EOPNOTSUPP; - if (dev->module_fw_flash_in_progress) + if (dev->ethtool->module_fw_flash_in_progress) return -EBUSY; if (copy_from_user(&reset, useraddr, sizeof(reset))) @@ -2588,7 +2588,7 @@ int ethtool_get_module_info_call(struct net_device *dev, const struct ethtool_ops *ops = dev->ethtool_ops; struct phy_device *phydev = dev->phydev; - if (dev->module_fw_flash_in_progress) + if (dev->ethtool->module_fw_flash_in_progress) return -EBUSY; if (dev->sfp_bus) @@ -2628,7 +2628,7 @@ int ethtool_get_module_eeprom_call(struct net_device *dev, const struct ethtool_ops *ops = dev->ethtool_ops; struct phy_device *phydev = dev->phydev; - if (dev->module_fw_flash_in_progress) + if (dev->ethtool->module_fw_flash_in_progress) return -EBUSY; if (dev->sfp_bus) diff --git a/net/ethtool/module.c b/net/ethtool/module.c index 6b7448df08d5..aba78436d350 100644 --- a/net/ethtool/module.c +++ b/net/ethtool/module.c @@ -37,7 +37,7 @@ static int module_get_power_mode(struct net_device *dev, if (!ops->get_module_power_mode) return 0; - if (dev->module_fw_flash_in_progress) { + if (dev->ethtool->module_fw_flash_in_progress) { NL_SET_ERR_MSG(extack, "Module firmware flashing is in progress"); return -EBUSY; @@ -119,7 +119,7 @@ ethnl_set_module_validate(struct ethnl_req_info *req_info, if (!tb[ETHTOOL_A_MODULE_POWER_MODE_POLICY]) return 0; - if (req_info->dev->module_fw_flash_in_progress) { + if (req_info->dev->ethtool->module_fw_flash_in_progress) { NL_SET_ERR_MSG(info->extack, "Module firmware flashing is in progress"); return -EBUSY; @@ -226,7 +226,7 @@ static void module_flash_fw_work(struct work_struct *work) ethtool_cmis_fw_update(&module_fw->fw_update); module_flash_fw_work_list_del(&module_fw->list); - module_fw->fw_update.dev->module_fw_flash_in_progress = false; + module_fw->fw_update.dev->ethtool->module_fw_flash_in_progress = false; netdev_put(module_fw->fw_update.dev, &module_fw->dev_tracker); release_firmware(module_fw->fw_update.fw); kfree(module_fw); @@ -318,7 +318,7 @@ module_flash_fw_schedule(struct net_device *dev, const char *file_name, if (err < 0) goto err_release_firmware; - dev->module_fw_flash_in_progress = true; + dev->ethtool->module_fw_flash_in_progress = true; netdev_hold(dev, &module_fw->dev_tracker, GFP_KERNEL); fw_update->dev = dev; fw_update->ntf_params.portid = info->snd_portid; @@ -385,7 +385,7 @@ static int ethnl_module_fw_flash_validate(struct net_device *dev, return -EOPNOTSUPP; } - if (dev->module_fw_flash_in_progress) { + if (dev->ethtool->module_fw_flash_in_progress) { NL_SET_ERR_MSG(extack, "Module firmware flashing already in progress"); return -EBUSY; } diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c index 81fe2e5b95f6..cb1eea00e349 100644 --- a/net/ethtool/netlink.c +++ b/net/ethtool/netlink.c @@ -807,7 +807,7 @@ static int ethnl_netdev_event(struct notifier_block *this, unsigned long event, ethnl_notify_features(ptr); break; case NETDEV_PRE_UP: - if (dev->module_fw_flash_in_progress) { + if (dev->ethtool->module_fw_flash_in_progress) { NL_SET_ERR_MSG(extack, "Can't set port up while flashing module firmware"); return NOTIFY_BAD; } . From: Maxime Chevallier To: davem@davemloft.net Cc: Maxime Chevallier , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Andrew Lunn , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Russell King , linux-arm-kernel@lists.infradead.org, Christophe Leroy , Herve Codina , Florian Fainelli , Heiner Kallweit , Vladimir Oltean , =?UTF-8?q?K=C3=B6ry=20Maincent?= , Jesse Brandeburg , =?UTF-8?q?Marek=20Beh=C3=BAn?= , Piergiorgio Beruto , Oleksij Rempel , =?UTF-8?q?Nicol=C3=B2=20Veronese?= , Simon Horman , mwojtas@chromium.org, Nathan Chancellor , Antoine Tenart , Marc Kleine-Budde , Dan Carpenter Subject: [PATCH net-next v15 00/14] Introduce PHY listing and link_topology tracking Date: Wed, 3 Jul 2024 16:07:50 +0200 Message-ID: <20240703140806.271938-1-maxime.chevallier@bootlin.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1266647 org.kernel.vger.netdev:355569 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hello everyone, This is V15 of the phy_link_topology series, aiming at improving support for multiple PHYs being attached to the same MAC. The main change in V15 is the introduction of patch 12, that drops a non-needed check on the genl_info parameter passed on the ethnl ops for strset. This extra check shouldn't be needed as the genl_info shouldn't be NULL, but it tricks smatch into thinking it can, thus generating some warnings in patch 13. Thanks Simon and Dan for the report. All other patches are left unchanged from V14, besides a net-next rebase. As a remainder, here's what the PHY listings would look like : - eth0 has a 88x3310 acting as media converter, and an SFP module with an embedded 88e1111 PHY - eth2 has a 88e1510 PHY # ethtool --show-phys * PHY for eth0: PHY index: 1 Driver name: mv88x3310 PHY device name: f212a600.mdio-mii:00 Downstream SFP bus name: sfp-eth0 PHY id: 0 Upstream type: MAC PHY for eth0: PHY index: 2 Driver name: Marvell 88E1111 PHY device name: i2c:sfp-eth0:16 PHY id: 21040322 Upstream type: PHY Upstream PHY index: 1 Upstream SFP name: sfp-eth0 PHY for eth2: PHY index: 1 Driver name: Marvell 88E1510 PHY device name: f212a200.mdio-mii:00 PHY id: 21040593 Upstream type: MAC Ethtool patches : https://github.com/minimaxwell/ethtool/tree/mc/topo-v14 Link to V14: https://lore.kernel.org/netdev/20240701131801.1227740-1-maxime.chevallier@bootlin.com/ Link to V13: https://lore.kernel.org/netdev/20240607071836.911403-1-maxime.chevallier@bootlin.com/ Link to v12: https://lore.kernel.org/netdev/20240605124920.720690-1-maxime.chevallier@bootlin.com/ Link to v11: https://lore.kernel.org/netdev/20240404093004.2552221-1-maxime.chevallier@bootlin.com/ Link to V10: https://lore.kernel.org/netdev/20240304151011.1610175-1-maxime.chevallier@bootlin.com/ Link to V9: https://lore.kernel.org/netdev/20240228114728.51861-1-maxime.chevallier@bootlin.com/ Link to V8: https://lore.kernel.org/netdev/20240220184217.3689988-1-maxime.chevallier@bootlin.com/ Link to V7: https://lore.kernel.org/netdev/20240213150431.1796171-1-maxime.chevallier@bootlin.com/ Link to V6: https://lore.kernel.org/netdev/20240126183851.2081418-1-maxime.chevallier@bootlin.com/ Link to V5: https://lore.kernel.org/netdev/20231221180047.1924733-1-maxime.chevallier@bootlin.com/ Link to V4: https://lore.kernel.org/netdev/20231215171237.1152563-1-maxime.chevallier@bootlin.com/ Link to V3: https://lore.kernel.org/netdev/20231201163704.1306431-1-maxime.chevallier@bootlin.com/ Link to V2: https://lore.kernel.org/netdev/20231117162323.626979-1-maxime.chevallier@bootlin.com/ Link to V1: https://lore.kernel.org/netdev/20230907092407.647139-1-maxime.chevallier@bootlin.com/ More discussions on specific issues that happened in 6.9-rc: https://lore.kernel.org/netdev/20240412104615.3779632-1-maxime.chevallier@bootlin.com/ https://lore.kernel.org/netdev/20240429131008.439231-1-maxime.chevallier@bootlin.com/ https://lore.kernel.org/netdev/20240507102822.2023826-1-maxime.chevallier@bootlin.com/ Maxime Chevallier (14): net: phy: Introduce ethernet link topology representation net: sfp: pass the phy_device when disconnecting an sfp module's PHY net: phy: add helpers to handle sfp phy connect/disconnect net: sfp: Add helper to return the SFP bus name net: ethtool: Allow passing a phy index for some commands netlink: specs: add phy-index as a header parameter net: ethtool: Introduce a command to list PHYs on an interface netlink: specs: add ethnl PHY_GET command set net: ethtool: plca: Target the command to the requested PHY net: ethtool: pse-pd: Target the command to the requested PHY net: ethtool: cable-test: Target the command to the requested PHY net: ethtool: strset: Remove unnecessary check on genl_info net: ethtool: strset: Allow querying phy stats by index Documentation: networking: document phy_link_topology Documentation/netlink/specs/ethtool.yaml | 62 ++++ Documentation/networking/ethtool-netlink.rst | 52 +++ Documentation/networking/index.rst | 1 + .../networking/phy-link-topology.rst | 121 +++++++ MAINTAINERS | 1 + drivers/net/phy/Makefile | 2 +- drivers/net/phy/marvell-88x2222.c | 2 + drivers/net/phy/marvell.c | 2 + drivers/net/phy/marvell10g.c | 2 + drivers/net/phy/phy_device.c | 48 +++ drivers/net/phy/phy_link_topology.c | 105 ++++++ drivers/net/phy/phylink.c | 3 +- drivers/net/phy/qcom/at803x.c | 2 + drivers/net/phy/qcom/qca807x.c | 2 + drivers/net/phy/sfp-bus.c | 15 +- include/linux/netdevice.h | 4 +- include/linux/phy.h | 6 + include/linux/phy_link_topology.h | 82 +++++ include/linux/sfp.h | 8 +- include/uapi/linux/ethtool.h | 16 + include/uapi/linux/ethtool_netlink.h | 21 ++ net/core/dev.c | 15 + net/ethtool/Makefile | 3 +- net/ethtool/cabletest.c | 35 +- net/ethtool/netlink.c | 66 +++- net/ethtool/netlink.h | 33 ++ net/ethtool/phy.c | 312 ++++++++++++++++++ net/ethtool/plca.c | 30 +- net/ethtool/pse-pd.c | 30 +- net/ethtool/strset.c | 27 +- 30 files changed, 1056 insertions(+), 52 deletions(-) create mode 100644 Documentation/networking/phy-link-topology.rst create mode 100644 drivers/net/phy/phy_link_topology.c create mode 100644 include/linux/phy_link_topology.h create mode 100644 net/ethtool/phy.c -- 2.45.1 . From: Ronald Wahl To: Ronald Wahl Cc: Ronald Wahl , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH] ks8851: Fix deadlock with the SPI chip variant Date: Wed, 3 Jul 2024 18:00:53 +0200 Message-ID: <20240703160053.9892-1-rwahl@gmx.de> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Xref: photonic.trudheim.com org.kernel.vger.netdev:355588 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.stable Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Ronald Wahl When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. This commit moves the netif_wake_queue call outside the spinlock protected area. Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overru= n") Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Ronald Wahl =2D-- drivers/net/ethernet/micrel/ks8851_common.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/eth= ernet/micrel/ks8851_common.c index 6453c92f0fa7..60b959126b26 100644 =2D-- a/drivers/net/ethernet/micrel/ks8851_common.c +++ b/drivers/net/ethernet/micrel/ks8851_common.c @@ -348,15 +348,17 @@ static irqreturn_t ks8851_irq(int irq, void *_ks) if (status & IRQ_TXI) { unsigned short tx_space =3D ks8851_rdreg16(ks, KS_TXMIR); + bool need_wake_queue; netif_dbg(ks, intr, ks->netdev, "%s: txspace %d\n", __func__, tx_space); spin_lock(&ks->statelock); ks->tx_space =3D tx_space; - if (netif_queue_stopped(ks->netdev)) - netif_wake_queue(ks->netdev); + need_wake_queue =3D netif_queue_stopped(ks->netdev); spin_unlock(&ks->statelock); + if (need_wake_queue) + netif_wake_queue(ks->netdev); } if (status & IRQ_SPIBEI) { =2D- 2.45.2 . 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 Subject: [PATCH net] bnxt_en: Fix the resource check condition for RSS contexts Date: Wed, 3 Jul 2024 11:01:12 -0700 Message-ID: <20240703180112.78590-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="000000000000dd3f21061c5ba15d" Xref: photonic.trudheim.com org.kernel.vger.netdev:355595 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail --000000000000dd3f21061c5ba15d Content-Transfer-Encoding: 8bit From: Pavan Chebbi While creating a new RSS context, bnxt_rfs_capable() currently makes a strict check to see if the required VNICs are already available. If the current VNICs are not what is required, either too many or not enough, it will call the firmware to reserve the exact number required. There is a bug in the firmware when the driver tries to relinquish some reserved VNICs and RSS contexts. It will cause the default VNIC to lose its RSS configuration and cause receive packets to be placed incorrectly. Workaround this problem by skipping the resource reduction. The driver will not reduce the VNIC and RSS context reservations when a context is deleted. The resources will be available for use when new contexts are created later. Potentially, this workaround can cause us to run out of VNIC and RSS contexts if there are a lot of VF functions creating and deleting RSS contexts. In the future, we will conditionally disable this workaround when the firmware fix is available. Fixes: 438ba39b25fe ("bnxt_en: Improve RSS context reservation infrastructure") Reported-by: Jakub Kicinski Link: https://lore.kernel.org/netdev/20240625010210.2002310-1-kuba@kernel.org/ Reviewed-by: Andy Gospodarek Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index a6d69a45fa01..53085058100c 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -12669,7 +12669,11 @@ bool bnxt_rfs_capable(struct bnxt *bp, bool new_rss_ctx) if (!BNXT_NEW_RM(bp)) return true; - if (hwr.vnic == bp->hw_resc.resv_vnics && + /* Do not reduce VNIC and RSS ctx reservations. There is a FW + * issue that will mess up the default VNIC if we reduce the + * reservations. + */ + if (hwr.vnic <= bp->hw_resc.resv_vnics && hwr.rss_ctx <= bp->hw_resc.resv_rsscos_ctxs) return true; -- 2.30.1 --000000000000dd3f21061c5ba15d 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 DQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEILgByXqD6+nRM7iMKH6H8uUsIqNd/C7P 3xRLv5SPI5z3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI0MDcw MzE4MDIyM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQC ATANBgkqhkiG9w0BAQEFAASCAQAbhzKZ2G65OIWAIY4YG8xxrVT8XTHCE+OPdSW218752lzibT4k +WPtFQ2aFYLsh89ZWnqm7EaLC2Xmn1bbP/5KxoOW0K31YTAE9adW9NLi0lv5baV7JYBKW5cjyvSx 7XxZ2yFVO1adEuQCgWUN5f/G1zmih9fHFkLlNUkrPvZWVRQsjWzj7RcAUJNW7pkmaw6KUMr17Jox 8cwrvUXZyOPC6u5yCR5OgikWYTWAJM0ES0O8U/ppaihhXYYoC8Vm4Q0OYK6qIavBh1PnZc/6WMSw WX+UUrxxARkZwe22RWafjObb/MJ6DARsBh7wQ1gJce35lAYSimDuyvvr/iYNBVD0 --000000000000dd3f21061c5ba15d-- . From: James Chapman To: netdev@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com, tparkin@katalix.com, James Chapman , syzbot+b471b7c936301a59745b@syzkaller.appspotmail.com, syzbot+c041b4ce3a6dfd1e63e2@syzkaller.appspotmail.com Subject: [PATCH net-next] l2tp: fix possible UAF when cleaning up tunnels Date: Wed, 3 Jul 2024 19:51:08 +0100 Message-Id: <20240703185108.1752795-1-jchapman@katalix.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1267039 org.kernel.vger.netdev:355599 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail syzbot reported a UAF caused by a race when the L2TP work queue closes a tunnel at the same time as a userspace thread closes a session in that tunnel. Tunnel cleanup is handled by a work queue which iterates through the sessions contained within a tunnel, and closes them in turn. Meanwhile, a userspace thread may arbitrarily close a session via either netlink command or by closing the pppox socket in the case of l2tp_ppp. The race condition may occur when l2tp_tunnel_closeall walks the list of sessions in the tunnel and deletes each one. Currently this is implemented using list_for_each_safe, but because the list spinlock is dropped in the loop body it's possible for other threads to manipulate the list during list_for_each_safe's list walk. This can lead to the list iterator being corrupted, leading to list_for_each_safe spinning. One sequence of events which may lead to this is as follows: * A tunnel is created, containing two sessions A and B. * A thread closes the tunnel, triggering tunnel cleanup via the work queue. * l2tp_tunnel_closeall runs in the context of the work queue. It removes session A from the tunnel session list, then drops the list lock. At this point the list_for_each_safe temporary variable is pointing to the other session on the list, which is session B, and the list can be manipulated by other threads since the list lock has been released. * Userspace closes session B, which removes the session from its parent tunnel via l2tp_session_delete. Since l2tp_tunnel_closeall has released the tunnel list lock, l2tp_session_delete is able to call list_del_init on the session B list node. * Back on the work queue, l2tp_tunnel_closeall resumes execution and will now spin forever on the same list entry until the underlying session structure is freed, at which point UAF occurs. The solution is to iterate over the tunnel's session list using list_first_entry_not_null to avoid the possibility of the list iterator pointing at a list item which may be removed during the walk. Reported-by: syzbot+b471b7c936301a59745b@syzkaller.appspotmail.com Reported-by: syzbot+c041b4ce3a6dfd1e63e2@syzkaller.appspotmail.com Fixes: d18d3f0a24f ("l2tp: replace hlist with simple list for per-tunnel session list") Signed-off-by: James Chapman Signed-off-by: Tom Parkin --- net/l2tp/l2tp_core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index 64f446f0930b..afa180b7b428 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1290,13 +1290,14 @@ static void l2tp_session_unhash(struct l2tp_session *session) static void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel) { struct l2tp_session *session; - struct list_head *pos; - struct list_head *tmp; spin_lock_bh(&tunnel->list_lock); tunnel->acpt_newsess = false; - list_for_each_safe(pos, tmp, &tunnel->session_list) { - session = list_entry(pos, struct l2tp_session, list); + for (;;) { + session = list_first_entry_or_null(&tunnel->session_list, + struct l2tp_session, list); + if (!session) + break; list_del_init(&session->list); spin_unlock_bh(&tunnel->list_lock); l2tp_session_delete(session); -- 2.34.1 . From: Aleksandr Mishin To: Jiri Pirko CC: Aleksandr Mishin , Ido Schimmel , Petr Machata , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , , , , Przemek Kitszel Subject: [PATCH net v2] mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file Date: Wed, 3 Jul 2024 23:32:51 +0300 Message-ID: <20240703203251.8871-1-amishin@t-argos.ru> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-KSMG-Rule-ID: 1 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 186316 [Jul 03 2024] X-KSMG-AntiSpam-Version: 6.1.0.4 X-KSMG-AntiSpam-Envelope-From: amishin@t-argos.ru X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 21 0.3.21 ebee5449fc125b2da45f1a6a6bc2c5c0c3ad0e05, {Tracking_uf_ne_domains}, {Tracking_from_domain_doesnt_match_to}, t-argos.ru:7.1.1;lore.kernel.org:7.1.1;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;127.0.0.199:7.1.2;mx1.t-argos.ru.ru:7.1.1, FromAlignment: s X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean, bases: 2024/07/03 19:52:00 X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2024/07/03 17:02:00 #25823003 X-KSMG-AntiVirus-Status: Clean, skipped Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1267117 org.kernel.vger.netdev:355601 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn't reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b217127e5e4e ("mlxsw: core_linecards: Add line card objects and implement provisioning") Signed-off-by: Aleksandr Mishin Reviewed-by: Przemek Kitszel Reviewed-by: Ido Schimmel --- v2: - fix few typos in comment as suggested by Przemek and Ido - add Reviewed-by: Przemek Kitszel (https://lore.kernel.org/all/c631fc5e-1cc6-467a-963a-69ef03c20f40@intel.com/) - add Reviewed-by: Ido Schimmel (https://lore.kernel.org/all/ZoWJzqaRJKjtTlNO@shredder.mtl.com/) v1: https://lore.kernel.org/all/20240702103352.15315-1-amishin@t-argos.ru/ drivers/net/ethernet/mellanox/mlxsw/core_linecards.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_linecards.c b/drivers/net/ethernet/mellanox/mlxsw/core_linecards.c index 025e0db983fe..b032d5a4b3b8 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/core_linecards.c +++ b/drivers/net/ethernet/mellanox/mlxsw/core_linecards.c @@ -1484,6 +1484,7 @@ static int mlxsw_linecard_types_init(struct mlxsw_core *mlxsw_core, vfree(types_info->data); err_data_alloc: kfree(types_info); + linecards->types_info = NULL; return err; } -- 2.30.2 .