- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] drm: Don't unref the same fb many times by mistake due to deadlock handling
by Jinjie Ruan 14 Mar '24

14 Mar '24

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> stable inclusion from stable-v5.10.210 commit f55261469be87c55df13db76dc945f6bcd825105 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NI1 CVE: CVE-2023-52486 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c upstream. If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. Cc: stable(a)vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-1-ville.… Acked-by: Javier Martinez Canillas <javierm(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/gpu/drm/drm_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 24f643982903..79249568bdec 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -1213,6 +1213,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, out: if (fb) drm_framebuffer_put(fb); + fb = NULL; if (plane->old_fb) drm_framebuffer_put(plane->old_fb); plane->old_fb = NULL; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm: Don't unref the same fb many times by mistake due to deadlock handling
by Jinjie Ruan 14 Mar '24

14 Mar '24

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> stable inclusion from stable-v5.10.210 commit f55261469be87c55df13db76dc945f6bcd825105 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NI1 CVE: CVE-2023-52486 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c upstream. If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. Cc: stable(a)vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-1-ville.… Acked-by: Javier Martinez Canillas <javierm(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/gpu/drm/drm_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 2411b6de055e..4c530900a208 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -1183,6 +1183,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, out: if (fb) drm_framebuffer_put(fb); + fb = NULL; if (plane->old_fb) drm_framebuffer_put(plane->old_fb); plane->old_fb = NULL; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 6/6] Add MODULE_FIRMWARE() for FIRMWARE_TG357766.
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Tobias Heider <me(a)tobhe.de> stable inclusion from stable-v5.10.188 commit c377451012cec94f01b6c698409fec865e55dd3f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 046f753da6143ee16452966915087ec8b0de3c70 ] Fixes a bug where on the M1 mac mini initramfs-tools fails to include the necessary firmware into the initrd. Fixes: c4dab50697ff ("tg3: Download 57766 EEE service patch firmware") Signed-off-by: Tobias Heider <me(a)tobhe.de> Reviewed-by: Michael Chan <michael.chan(a)broadcom.com> Link: https://lore.kernel.org/r/ZJt7LKzjdz8+dClx@tobhe.de Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/tg3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c index 9eb716acac04..39bef1809a97 100644 --- a/drivers/net/ethernet/broadcom/tg3.c +++ b/drivers/net/ethernet/broadcom/tg3.c @@ -224,6 +224,7 @@ MODULE_AUTHOR("David S. Miller (davem(a)redhat.com) and Jeff Garzik (jgarzik@pobox MODULE_DESCRIPTION("Broadcom Tigon3 ethernet driver"); MODULE_LICENSE("GPL"); MODULE_FIRMWARE(FIRMWARE_TG3); +MODULE_FIRMWARE(FIRMWARE_TG357766); MODULE_FIRMWARE(FIRMWARE_TG3TSO); MODULE_FIRMWARE(FIRMWARE_TG3TSO5); -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 5/6] bnxt_en: Implement .set_port / .unset_port UDP tunnel callbacks
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Somnath Kotur <somnath.kotur(a)broadcom.com> stable inclusion from stable-v5.10.184 commit 3f6dfff5fe416bda6469cf235eaa9c54fee2a0bc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1eb4ef12591348c440ac9d6efcf7521e73cf2b10 ] As per the new udp tunnel framework, drivers which need to know the details of a port entry (i.e. port type) when it gets deleted should use the .set_port / .unset_port callbacks. Implementing the current .udp_tunnel_sync callback would mean that the deleted tunnel port entry would be all zeros. This used to work on older firmware because it would not check the input when deleting a tunnel port. With newer firmware, the delete will now fail and subsequent tunnel port allocation will fail as a result. Fixes: 442a35a5a7aa ("bnxt: convert to new udp_tunnel_nic infra") Reviewed-by: Kalesh Anakkur Purayil <kalesh-anakkur.purayil(a)broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur(a)broadcom.com> Signed-off-by: Michael Chan <michael.chan(a)broadcom.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 25 ++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 4db84ed9d698..3dc826353b02 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -12099,26 +12099,37 @@ static void bnxt_cfg_ntp_filters(struct bnxt *bp) #endif /* CONFIG_RFS_ACCEL */ -static int bnxt_udp_tunnel_sync(struct net_device *netdev, unsigned int table) +static int bnxt_udp_tunnel_set_port(struct net_device *netdev, unsigned int table, + unsigned int entry, struct udp_tunnel_info *ti) { struct bnxt *bp = netdev_priv(netdev); - struct udp_tunnel_info ti; unsigned int cmd; - udp_tunnel_nic_get_port(netdev, table, 0, &ti); - if (ti.type == UDP_TUNNEL_TYPE_VXLAN) + if (ti->type == UDP_TUNNEL_TYPE_VXLAN) cmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN; else cmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE; - if (ti.port) - return bnxt_hwrm_tunnel_dst_port_alloc(bp, ti.port, cmd); + return bnxt_hwrm_tunnel_dst_port_alloc(bp, ti->port, cmd); +} + +static int bnxt_udp_tunnel_unset_port(struct net_device *netdev, unsigned int table, + unsigned int entry, struct udp_tunnel_info *ti) +{ + struct bnxt *bp = netdev_priv(netdev); + unsigned int cmd; + + if (ti->type == UDP_TUNNEL_TYPE_VXLAN) + cmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN; + else + cmd = TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE; return bnxt_hwrm_tunnel_dst_port_free(bp, cmd); } static const struct udp_tunnel_nic_info bnxt_udp_tunnels = { - .sync_table = bnxt_udp_tunnel_sync, + .set_port = bnxt_udp_tunnel_set_port, + .unset_port = bnxt_udp_tunnel_unset_port, .flags = UDP_TUNNEL_NIC_INFO_MAY_SLEEP | UDP_TUNNEL_NIC_INFO_OPEN_ONLY, .tables = { -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 4/6] bnxt_en: Query default VLAN before VNIC setup on a VF
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Somnath Kotur <somnath.kotur(a)broadcom.com> stable inclusion from stable-v5.10.184 commit deead0d8729f33f47cbedd0010a7e0e381527f9b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1a9e4f501bc6ff1b6ecb60df54fbf2b54db43bfe ] We need to call bnxt_hwrm_func_qcfg() on a VF to query the default VLAN that may be setup by the PF. If a default VLAN is enabled, the VF cannot support VLAN acceleration on the receive side and the VNIC must be setup to strip out the default VLAN tag. If a default VLAN is not enabled, the VF can support VLAN acceleration on the receive side. The VNIC should be set up to strip or not strip the VLAN based on the RX VLAN acceleration setting. Without this call to determine the default VLAN before calling bnxt_setup_vnic(), the VNIC may not be set up correctly. For example, bnxt_setup_vnic() may set up to strip the VLAN tag based on stale default VLAN information. If RX VLAN acceleration is not enabled, the VLAN tag will be incorrectly stripped and the RX data path will not work correctly. Fixes: cf6645f8ebc6 ("bnxt_en: Add function for VF driver to query default VLAN.") Reviewed-by: Pavan Chebbi <pavan.chebbi(a)broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur(a)broadcom.com> Signed-off-by: Michael Chan <michael.chan(a)broadcom.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index b818d5f342d5..4db84ed9d698 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -8336,6 +8336,9 @@ static int bnxt_init_chip(struct bnxt *bp, bool irq_re_init) goto err_out; } + if (BNXT_VF(bp)) + bnxt_hwrm_func_qcfg(bp); + rc = bnxt_setup_vnic(bp, 0); if (rc) goto err_out; -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 3/6] bnxt_en: Don't issue AP reset during ethtool's reset operation
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com> stable inclusion from stable-v5.10.184 commit 84dbd27ad5dace21830c67d01470e9121a044b22 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1d997801c7cc6a7f542e46d5a6bf16f893ad3fe9 ] Only older NIC controller's firmware uses the PROC AP reset type. Firmware on 5731X/5741X and newer chips does not support this reset type. When bnxt_reset() issues a series of resets, this PROC AP reset may actually fail on these newer chips because the firmware is not ready to accept this unsupported command yet. Avoid this unnecessary error by skipping this reset type on chips that don't support it. Fixes: 7a13240e3718 ("bnxt_en: fix ethtool_reset_flags ABI violations") Reviewed-by: Pavan Chebbi <pavan.chebbi(a)broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy(a)broadcom.com> Signed-off-by: Michael Chan <michael.chan(a)broadcom.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c index d90b7b85c052..310c1d72205f 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c @@ -3446,7 +3446,7 @@ static int bnxt_reset(struct net_device *dev, u32 *flags) } } - if (req & BNXT_FW_RESET_AP) { + if (!BNXT_CHIP_P4_PLUS(bp) && (req & BNXT_FW_RESET_AP)) { /* This feature is not supported in older firmware versions */ if (bp->hwrm_spec_code >= 0x10803) { if (!bnxt_firmware_reset_ap(dev)) { -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 2/6] net: bcmgenet: Restore phy_stop() depending upon suspend/close
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Florian Fainelli <f.fainelli(a)gmail.com> stable inclusion from stable-v5.10.181 commit 43f6575004e0bbe0acc5d7a1955f326b22f38121 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 225c657945c4a6307741cb3cc89467eadcc26e9b ] Removing the phy_stop() from bcmgenet_netif_stop() ended up causing warnings from the PHY library that phy_start() is called from the RUNNING state since we are no longer stopping the PHY state machine during bcmgenet_suspend(). Restore the call to phy_stop() but make it conditional on being called from the close or suspend path. Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine") Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi(a)broadcom.com> Link: https://lore.kernel.org/r/20230515025608.2587012-1-f.fainelli@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c index 52c93701a9e4..f198144a7ce1 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -3393,7 +3393,7 @@ static int bcmgenet_open(struct net_device *dev) return ret; } -static void bcmgenet_netif_stop(struct net_device *dev) +static void bcmgenet_netif_stop(struct net_device *dev, bool stop_phy) { struct bcmgenet_priv *priv = netdev_priv(dev); @@ -3408,6 +3408,8 @@ static void bcmgenet_netif_stop(struct net_device *dev) /* Disable MAC transmit. TX DMA disabled must be done before this */ umac_enable_set(priv, CMD_TX_EN, false); + if (stop_phy) + phy_stop(dev->phydev); bcmgenet_disable_rx_napi(priv); bcmgenet_intr_disable(priv); @@ -3433,7 +3435,7 @@ static int bcmgenet_close(struct net_device *dev) netif_dbg(priv, ifdown, dev, "bcmgenet_close\n"); - bcmgenet_netif_stop(dev); + bcmgenet_netif_stop(dev, false); /* Really kill the PHY state machine and disconnect from it */ phy_disconnect(dev->phydev); @@ -4235,7 +4237,7 @@ static int bcmgenet_suspend(struct device *d) netif_device_detach(dev); - bcmgenet_netif_stop(dev); + bcmgenet_netif_stop(dev, true); if (!device_may_wakeup(d)) phy_suspend(dev->phydev); -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 1/6] net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Florian Fainelli <f.fainelli(a)gmail.com> stable inclusion from stable-v5.10.181 commit e92727ed9e8b6798efc1e7ae44bbe7c44c453670 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8L4MY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 93e0401e0fc0c54b0ac05b687cd135c2ac38187c ] The call to phy_stop() races with the later call to phy_disconnect(), resulting in concurrent phy_suspend() calls being run from different CPUs. The final call to phy_disconnect() ensures that the PHY is stopped and suspended, too. Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dapeng Yu <dapeng.yu(a)windriver.com> --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c index 6ee6c34f28f2..52c93701a9e4 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -3408,7 +3408,6 @@ static void bcmgenet_netif_stop(struct net_device *dev) /* Disable MAC transmit. TX DMA disabled must be done before this */ umac_enable_set(priv, CMD_TX_EN, false); - phy_stop(dev->phydev); bcmgenet_disable_rx_napi(priv); bcmgenet_intr_disable(priv); -- 2.43.0

1 0

[PATCH openEuler-22.03-LTS-SP1 0/6] Upgrade driver for Broadcom NIC BCM57414
by Dapeng Yu 14 Mar '24

14 Mar '24

From: Dapeng Yu <dapeng.yu(a)windriver.com> Upgrade driver for Broadcom NIC BCM57414 Florian Fainelli (2): net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop() net: bcmgenet: Restore phy_stop() depending upon suspend/close Somnath Kotur (2): bnxt_en: Query default VLAN before VNIC setup on a VF bnxt_en: Implement .set_port / .unset_port UDP tunnel callbacks Sreekanth Reddy (1): bnxt_en: Don't issue AP reset during ethtool's reset operation Tobias Heider (1): Add MODULE_FIRMWARE() for FIRMWARE_TG357766. drivers/net/ethernet/broadcom/bnxt/bnxt.c | 28 ++++++++++++++----- .../net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 2 +- .../net/ethernet/broadcom/genet/bcmgenet.c | 9 +++--- drivers/net/ethernet/broadcom/tg3.c | 1 + 4 files changed, 28 insertions(+), 12 deletions(-) -- 2.43.0

1 0

[PATCH OLK-5.10] dmaengine: fix NULL pointer in channel unregistration function
by Zheng Yejian 14 Mar '24

14 Mar '24

From: Amelie Delaunay <amelie.delaunay(a)foss.st.com> stable inclusion from stable-v5.10.210 commit 9de69732dde4e443c1c7f89acbbed2c45a6a8e17 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NHW CVE: CVE-2023-52492 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit f5c24d94512f1b288262beda4d3dcb9629222fc7 ] __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function. Fixes: d2fb0a043838 ("dmaengine: break out channel registration") Signed-off-by: Amelie Delaunay <amelie.delaunay(a)foss.st.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://lore.kernel.org/r/20231213160452.2598073-1-amelie.delaunay@foss.st.… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/dma/dmaengine.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 4ec7bb58c195..9559ebd61f3b 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1108,6 +1108,9 @@ EXPORT_SYMBOL_GPL(dma_async_device_channel_register); static void __dma_async_device_channel_unregister(struct dma_device *device, struct dma_chan *chan) { + if (chan->local == NULL) + return; + WARN_ONCE(!device->device_release && chan->client_count, "%s called while %d clients hold a reference\n", __func__, chan->client_count); -- 2.25.1

2 1