- 15 May, 2023 18 commits
-
-
Dario Binacchi authored
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. ------------------------------------------------------------------------- | features | CAN1 | CAN2 | CAN 3 | ------------------------------------------------------------------------- | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | ------------------------------------------------------------------------- | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | ------------------------------------------------------------------------- Signed-off-by:Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-6-dario.binacchi@amarulasolutions.comSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Dario Binacchi authored
Add support for bxCAN controller in single peripheral configuration: - primary bxCAN - dedicated Memory Access Controller unit - 512-byte SRAM memory - 14 filter banks Signed-off-by:
-
Dario Binacchi authored
Add pin configurations for using CAN controller on stm32f7. Signed-off-by:
-
Dario Binacchi authored
This is a preparation patch for the upcoming support to manage CAN peripherals in single configuration. The addition ensures backwards compatibility. Signed-off-by:
-
Dario Binacchi authored
On the stm32f7 Socs the can peripheral can be in single or dual configuration. In the dual configuration, in turn, it can be in primary or secondary mode. The addition of the 'st,can-secondary' property allows you to specify this mode in the dual configuration. CAN peripheral nodes in single configuration contain neither "st,can-primary" nor "st,can-secondary". Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230427204540.3126234-2-dario.binacchi@amarulasolutions.comSigned-off-by:
-
Geert Uytterhoeven authored
The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is only present on STM32 SoCs. Hence drop the "|| OF" part from its dependency rule, to prevent asking the user about this driver when configuring a kernel without STM32 SoC support. Fixes: f00647d8 ("can: bxcan: add support for ST bxCAN controller") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.beSigned-off-by:
-
Oliver Hartkopp authored
can_put_echo_skb() checks for the enabled IFF_ECHO flag and the correct ETH_P type of the given skbuff. When implementing the CAN XL support the new check for ETH_P_CANXL has been forgotten. Fixes: fb08cba1 ("can: canxl: update CAN infrastructure for CAN XL frames") Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230506184515.39241-1-socketcan@hartkopp.netSigned-off-by:
-
Oliver Hartkopp authored
The control message provided by J1939 support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <o.rempel@pengutronix.de> Suggested-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
-
Oliver Hartkopp authored
The control message provided by isotp support MSG_CMSG_COMPAT but blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user space on 64 bit kernels. Link: https://github.com/hartkopp/can-isotp/issues/59 Cc: Oleksij Rempel <o.rempel@pengutronix.de> Suggested-by:
-
Russell King (Oracle) authored
While testing a Fiberstore SFP-10G-T module (which uses 10GBASE-R with rate adaption) in a Clearfog platform (which can't do that) it was found that the PHYs advertisement was not limited according to the hosts capabilities when using ethtool to change it. Fix this by ensuring that we mask the advertisement with the computed support mask as the very first thing we do. Fixes: cbc1bb1e ("net: phylink: simplify phy case for ksettings_set method") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Xin Long says: ==================== tipc: fix the mtu update in link mtu negotiation This patchset fixes a crash caused by a too small MTU carried in the activate msg. Note that as such malicious packet does not exist in the normal env, the fix won't break any application The 1st patch introduces a function to calculate the minimum MTU for the bearer, and the 2nd patch fixes the crash with this helper. While at it, the 3rd patch fixes the udp bearer mtu update by netlink with this helper. ==================== Reviewed-by:
Tung Nguyen <tung.q.nguyen@dektech.com.au> Signed-off-by:
-
Xin Long authored
Checking the bearer min mtu with tipc_udp_mtu_bad() only works for IPv4 UDP bearer, and IPv6 UDP bearer has a different value for the min mtu. This patch checks with encap_hlen + TIPC_MIN_BEARER_MTU for min mtu, which works for both IPv4 and IPv6 UDP bearer. Note that tipc_udp_mtu_bad() is still used to check media min mtu in __tipc_nl_media_set(), as m->mtu currently is only used by the IPv4 UDP bearer as its default mtu value. Fixes: 682cd3cf ("tipc: confgiure and apply UDP bearer MTU on running links") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
-
Xin Long authored
When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4! And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small. Fixes: ed193ece ("tipc: simplify link mtu negotiation") Reported-by:
Shuang Li <shuali@redhat.com> Signed-off-by:
-
Xin Long authored
As different media may requires different min mtu, and even the same media with different net family requires different min mtu, add tipc_bearer_min_mtu() to calculate min mtu accordingly. This API will be used to check the new mtu when doing the link mtu negotiation in the next patch. Signed-off-by:
-
Russell King (Oracle) authored
Commit 87e3bee0 ("net: mdio: i2c: Separate C22 and C45 transactions") separated the non-rollball bus accessors, but left the rollball accessors as is. As rollball accessors are clause 45, this results in the rollball protocol being completely non-functional. Fix this. Fixes: 87e3bee0 ("net: mdio: i2c: Separate C22 and C45 transactions") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Feng Liu authored
When initializing XDP in virtnet_open(), some rq xdp initialization may hit an error causing net device open failed. However, previous rqs have already initialized XDP and enabled NAPI, which is not the expected behavior. Need to roll back the previous rq initialization to avoid leaks in error unwinding of init code. Also extract helper functions of disable and enable queue pairs. Use newly introduced disable helper function in error unwinding and virtnet_close. Use enable helper function in virtnet_open. Fixes: 754b8a21 ("virtio_net: setup xdp_rxq_info") Signed-off-by:
Feng Liu <feliu@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
William Tu <witu@nvidia.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by:
-
Shenwei Wang authored
In the implementation, the sent_frame count does not increment when transmit errors occur. Therefore, bq_xmit_all() will take care of returning the XDP frames. Fixes: 26312c68 ("net: fec: correct the counting of XDP sent frames") Signed-off-by:
Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Dong Chenchen authored
As the call trace shows, skb_panic was caused by wrong skb->mac_header in nsh_gso_segment(): invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1 RIP: 0010:skb_panic+0xda/0xe0 call Trace: skb_push+0x91/0xa0 nsh_gso_segment+0x4f3/0x570 skb_mac_gso_segment+0x19e/0x270 __skb_gso_segment+0x1e8/0x3c0 validate_xmit_skb+0x452/0x890 validate_xmit_skb_list+0x99/0xd0 sch_direct_xmit+0x294/0x7c0 __dev_queue_xmit+0x16f0/0x1d70 packet_xmit+0x185/0x210 packet_snd+0xc15/0x1170 packet_sendmsg+0x7b/0xa0 sock_sendmsg+0x14f/0x160 The root cause is: nsh_gso_segment() use skb->network_header - nhoff to reset mac_header in skb_gso_error_unwind() if inner-layer protocol gso fails. However, skb->network_header may be reset by inner-layer protocol gso function e.g. mpls_gso_segment. skb->mac_header reset by the inaccurate network_header will be larger than skb headroom. nsh_gso_segment nhoff = skb->network_header - skb->mac_header; __skb_pull(skb,nsh_len) skb_mac_gso_segment mpls_gso_segment skb_reset_network_header(skb);//skb->network_header+=nsh_len return -EINVAL; skb_gso_error_unwind skb_push(skb, nsh_len); skb->mac_header = skb->network_header - nhoff; // skb->mac_header > skb->headroom, cause skb_push panic Use correct mac_offset to restore mac_header and get rid of nhoff. Fixes: c411ed85 ("nsh: add GSO support") Reported-by: syzbot+632b5d9964208bfef8c0@syzkaller.appspotmail.com Suggested-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
Dong Chenchen <dongchenchen2@huawei.com> Signed-off-by:
-
- 13 May, 2023 10 commits
-
-
David S. Miller authored
Hao Lan says: ==================== net: hns3: fix some bug for hns3 There are some bugfixes for the HNS3 ethernet driver. patch#1 fix miss checking for rx packet. patch#2 fixes VF promisc mode not update when mac table full bug, and patch#3 fixes a nterrupts not initialization in VF FLR bug. ==================== Signed-off-by: -
Jijie Shao authored
The timeout of the cmdq reset command has been increased to resolve the reset timeout issue in the full VF scenario. The timeout of other cmdq commands remains unchanged. Fixes: 8d307f8e ("net: hns3: create new set of unified hclge_comm_cmd_send APIs") Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Jie Wang authored
Currently the hns3 vf function reset delays 5000ms before vf rebuild process. In product applications, this delay is too long for application configurations and causes configuration timeout. According to the tests, 500ms delay is enough for reset process except PF FLR. So this patch modifies delay to 500ms in these scenarios. Fixes: 6988eb2a ("net: hns3: Add support to reset the enet/ring mgmt layer") Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
-
Jijie Shao authored
To prevent the system from abnormally sending PFC frames after an abnormal reset. The hns3 driver notifies the firmware to disable pfc before reset. Fixes: 35d93a30 ("net: hns3: adjust the process of PF reset") Signed-off-by:
-
Jie Wang authored
In function hns3_dump_tx_queue_info, The print buffer is not enough when the tx BD number is configured to 32760. As a result several BD information wouldn't be displayed. So fix it by increasing the tx queue print buffer length. Fixes: 630a6738 ("net: hns3: adjust string spaces of some parameters of tx bd info in debugfs") Signed-off-by:
-
David S. Miller authored
Alexis Lothoré says: ==================== net: dsa: rzn1-a5psw: fix STP states handling This small series fixes STP support and while adding a new function to enable/disable learning, use that to disable learning on standalone ports at switch setup as reported by Vladimir Oltean. This series was initially submitted on net-next by Clement Leger, but some career evolutions has made him hand me over those topics. Also, this new revision is submitted on net instead of net-next for V1 based on Vladimir Oltean's suggestion Changes since v2: - fix commit split by moving A5PSW_MGMT_CFG_ENABLE in relevant commit - fix reverse christmas tree ordering in a5psw_port_stp_state_set Changes since v1: - fix typos in commit messages and doc - re-split STP states handling commit - add Fixes: tag and new Signed-off-by - submit series as fix on net instead of net-next - split learning and blocking setting functions - remove unused define A5PSW_PORT_ENA_TX_SHIFT - add boolean for tx/rx enabled for clarity ==================== Signed-off-by: -
Clément Léger authored
When ports are in standalone mode, they should have learning disabled to avoid adding new entries in the MAC lookup table which might be used by other bridge ports to forward packets. While adding that, also make sure learning is enabled for CPU port. Fixes: 888cdb89 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by:
Clément Léger <clement.leger@bootlin.com> Signed-off-by:
Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by:
Piotr Raczynski <piotr.raczynski@intel.com> Signed-off-by:
-
Alexis Lothoré authored
stp_set_state() should actually allow receiving BPDU while in LEARNING mode which is not the case. Additionally, the BLOCKEN bit does not actually forbid sending forwarded frames from that port. To fix this, add a5psw_port_tx_enable() function which allows to disable TX. However, while its name suggest that TX is totally disabled, it is not and can still allow to send BPDUs even if disabled. This can be done by using forced forwarding with the switch tagging mechanism but keeping "filtering" disabled (which is already the case in the rzn1-a5sw tag driver). With these fixes, STP support is now functional. Fixes: 888cdb89 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by:
-
Clément Léger authored
Currently, management frame were discarded before reaching the CPU port due to a misconfiguration of the MGMT_CONFIG register. Enable them by setting the correct value in this register in order to correctly receive management frame and handle STP. Fixes: 888cdb89 ("net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver") Signed-off-by:
-
Xin Long authored
In commit 20704bd1 ("erspan: build the header with the right proto according to erspan_ver"), it gets the proto with t->parms.erspan_ver, but t->parms.erspan_ver is not used by collect_md branch, and instead it should get the proto with md->version for collect_md. Thanks to Kevin for pointing this out. Fixes: 20704bd1 ("erspan: build the header with the right proto according to erspan_ver") Fixes: 94d7d8f2 ("ip6_gre: add erspan v2 support") Reported-by:
Kevin Traynor <ktraynor@redhat.com> Signed-off-by:
William Tu <u9012063@gmail.com> Signed-off-by:
-
- 12 May, 2023 12 commits
-
-
Eric Dumazet authored
When tcp_v4_send_reset() is called with @sk == NULL, we do not change ctl_sk->sk_priority, which could have been set from a prior invocation. Change tcp_v4_send_reset() to set sk_priority and sk_mark fields before calling ip_send_unicast_reply(). This means tcp_v4_send_reset() and tcp_v4_send_ack() no longer have to clear ctl_sk->sk_mark after their call to ip_send_unicast_reply(). Fixes: f6c0f5d2 ("tcp: honor SO_PRIORITY in TIME_WAIT state") Signed-off-by:
-
Zhuang Shengen authored
When client and server establish a connection through vsock, the client send a request to the server to initiate the connection, then start a timer to wait for the server's response. When the server's RESPONSE message arrives, the timer also times out and exits. The server's RESPONSE message is processed first, and the connection is established. However, the client's timer also times out, the original processing logic of the client is to directly set the state of this vsock to CLOSE and return ETIMEDOUT. It will not notify the server when the port is released, causing the server port remain. when client's vsock_connect timeout，it should check sk state is ESTABLISHED or not. if sk state is ESTABLISHED, it means the connection is established, the client should not set the sk state to CLOSE Note: I encountered this issue on kernel-4.18, which can be fixed by this patch. Then I checked the latest code in the community and found similar issue. Fixes: d021c344 ("VSOCK: Introduce VM Sockets") Signed-off-by:
Zhuang Shengen <zhuangshengen@huawei.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Pieter Jansen van Vuuren authored
By default we would not want RXFCS and RXALL features enabled as they are mainly intended for debugging purposes. This does not stop users from enabling them later on as needed. Fixes: 8e57daf7 ("sfc_ef100: RX path for EF100") Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Co-developed-by:
Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by:
-
Jan Sokolowski authored
As not all ICE_TX_FLAGS_* fit in current 16-bit limited tx_flags field that was introduced in the Fixes commit, VLAN-related information would be discarded completely. As such, creating a vlan and trying to run ping through would result in no traffic passing. Fix that by refactoring tx_flags variable into flags only and a separate variable that holds VLAN ID. As there is some space left, type variable can fit between those two. Pahole reports no size change to ice_tx_buf struct. Fixes: aa1d3faf ("ice: Robustify cleaning/completing XDP Tx buffers") Signed-off-by:
Jan Sokolowski <jan.sokolowski@intel.com> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Jakub Kicinski authored
It seems that we mostly get netdev CCed on wireless patches which are written by people who don't know any better and CC everything that get_maintainers spits out. Rather than patches which indeed could benefit from general networking review. Marking them down in patchwork as Awaiting Upstream is a bit tedious. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Kalle Valo <kvalo@kernel.org> Signed-off-by:
-
Huayu Chen authored
The patch corrects the NFP_NET_MAX_DSCP definition in the main.h file. The incorrect definition result DSCP bits not being mapped properly when DCB is set. When NFP_NET_MAX_DSCP was defined as 4, the next 60 DSCP bits failed to be set. Fixes: 9b7fe804 ("nfp: add DCB IEEE support") Cc: stable@vger.kernel.org Signed-off-by:
Huayu Chen <huayu.chen@corigine.com> Acked-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
-
Jakub Kicinski authored
Documentation/netlink/ contains machine-readable protocol specs in YAML. Those are much like device tree bindings, no point CCing docs@ for the changes. Signed-off-by:
-
Marcelo Ricardo Leitner authored
Neil moved away from SCTP related duties. Move him to CREDITS then and while at it, update SCTP project website. Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
-
Grygorii Strashko authored
Introduce the W/A for packet errors seen with short cables (<1m) between two DP83867 PHYs. The W/A recommended by DM requires FFE Equalizer Configuration tuning by writing value 0x0E81 to DSP_FFE_CFG register (0x012C), surrounded by hard and soft resets as follows: write_reg(0x001F, 0x8000); //hard reset write_reg(DSP_FFE_CFG, 0x0E81); write_reg(0x001F, 0x4000); //soft reset Since DP83867 PHY DM says "Changing this register to 0x0E81, will not affect Long Cable performance.", enable the W/A by default. Fixes: 2a10154a ("net: phy: dp83867: Add TI dp83867 phy") Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by:
-
Uwe Kleine-König authored
In the (unlikely) event that pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is that the driver core ignores the error value and continues removing the device. This results in a resource leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the register mapping is already gone which probably results in a crash. Fixes: a31eda65 ("net: fec: fix clock count mis-match") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Eric Dumazet authored
After blamed commit, nexthop_fib6_nh_bh() and nexthop_fib6_nh() are the same. Delete nexthop_fib6_nh_bh(), and convert /proc/net/ipv6_route to standard rcu to avoid this splat: [ 5723.180080] WARNING: suspicious RCU usage [ 5723.180083] ----------------------------- [ 5723.180084] include/net/nexthop.h:516 suspicious rcu_dereference_check() usage! [ 5723.180086] other info that might help us debug this: [ 5723.180087] rcu_scheduler_active = 2, debug_locks = 1 [ 5723.180089] 2 locks held by cat/55856: [ 5723.180091] #0: ffff9440a582afa8 (&p->lock){+.+.}-{3:3}, at: seq_read_iter (fs/seq_file.c:188) [ 5723.180100] #1: ffffffffaac07040 (rcu_read_lock_bh){....}-{1:2}, at: rcu_lock_acquire (include/linux/rcupdate.h:326) [ 5723.180109] stack backtrace: [ 5723.180111] CPU: 14 PID: 55856 Comm: cat Tainted: G S I 6.3.0-dbx-DEV #528 [ 5723.180115] Call Trace: [ 5723.180117] <TASK> [ 5723.180119] dump_stack_lvl (lib/dump_stack.c:107) [ 5723.180124] dump_stack (lib/dump_stack.c:114) [ 5723.180126] lockdep_rcu_suspicious (include/linux/context_tracking.h:122) [ 5723.180132] ipv6_route_seq_show (include/net/nexthop.h:?) [ 5723.180135] ? ipv6_route_seq_next (net/ipv6/ip6_fib.c:2605) [ 5723.180140] seq_read_iter (fs/seq_file.c:272) [ 5723.180145] seq_read (fs/seq_file.c:163) [ 5723.180151] proc_reg_read (fs/proc/inode.c:316 fs/proc/inode.c:328) [ 5723.180155] vfs_read (fs/read_write.c:468) [ 5723.180160] ? up_read (kernel/locking/rwsem.c:1617) [ 5723.180164] ksys_read (fs/read_write.c:613) [ 5723.180168] __x64_sys_read (fs/read_write.c:621) [ 5723.180170] do_syscall_64 (arch/x86/entry/common.c:?) [ 5723.180174] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) [ 5723.180177] RIP: 0033:0x7fa455677d2a Fixes: 09eed119 ("neighbour: switch to standard rcu, instead of rcu_bh") Reported-by:syzbot <syzkaller@googlegroups.com> Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230510154646.370659-1-edumazet@google.comSigned-off-by:
-
Jiri Pirko authored
The commit 565b4824 ("devlink: change port event netdev notifier from per-net to global") changed original per-net notifier to be per-devlink instance. That fixed the issue of non-receiving events of netdev uninit if that moved to a different namespace. That worked fine in -net tree. However, later on when commit ee75f1fc ("net/mlx5e: Create separate devlink instance for ethernet auxiliary device") and commit 72ed5d56 ("net/mlx5: Suspend auxiliary devices only in case of PCI device suspend") were merged, a deadlock was introduced when removing a namespace with devlink instance with another nested instance. Here there is the bad flow example resulting in deadlock with mlx5: net_cleanup_work -> cleanup_net (takes down_read(&pernet_ops_rwsem) -> devlink_pernet_pre_exit() -> devlink_reload() -> mlx5_devlink_reload_down() -> mlx5_unload_one_devl_locked() -> mlx5_detach_device() -> del_adev() -> mlx5e_remove() -> mlx5e_destroy_devlink() -> devlink_free() -> unregister_netdevice_notifier() (takes down_write(&pernet_ops_rwsem) Steps to reproduce: $ modprobe mlx5_core $ ip netns add ns1 $ devlink dev reload pci/0000:08:00.0 netns ns1 $ ip netns del ns1 Resolve this by converting the notifier from per-devlink instance to a static one registered during init phase and leaving it registered forever. Use this notifier for all devlink port instances created later on. Note what a tree needs this fix only in case all of the cited fixes commits are present. Reported-by:
Moshe Shemesh <moshe@nvidia.com> Fixes: 565b4824 ("devlink: change port event netdev notifier from per-net to global") Fixes: ee75f1fc ("net/mlx5e: Create separate devlink instance for ethernet auxiliary device") Fixes: 72ed5d56 ("net/mlx5: Suspend auxiliary devices only in case of PCI device suspend") Signed-off-by:
-
