[PATCH net] benet: fix BUG when creating VFs

[PATCH net] benet: fix BUG when creating VFs

[Michal Schmidt]

benet crashes as soon as SRIOV VFs are created:

 kernel BUG at mm/vmalloc.c:3457!
 Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
 CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)
 [...]
 RIP: 0010:vunmap+0x5f/0x70
 [...]
 Call Trace:
  <TASK>
  __iommu_dma_free+0xe8/0x1c0
  be_cmd_set_mac_list+0x3fe/0x640 [be2net]
  be_cmd_set_mac+0xaf/0x110 [be2net]
  be_vf_eth_addr_config+0x19f/0x330 [be2net]
  be_vf_setup+0x4f7/0x990 [be2net]
  be_pci_sriov_configure+0x3a1/0x470 [be2net]
  sriov_numvfs_store+0x20b/0x380
  kernfs_fop_write_iter+0x354/0x530
  vfs_write+0x9b9/0xf60
  ksys_write+0xf3/0x1d0
  do_syscall_64+0x8c/0x3d0

be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.
Fix it by freeing only after the lock has been released.

Fixes: 1a82d19ca2d6 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink")
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index d730af4a50c7..bb5d2fa15736 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -3856,8 +3856,8 @@ int be_cmd_set_mac_list(struct be_adapter *adapter, u8 *mac_array,
 	status = be_mcc_notify_wait(adapter);
 
 err:
-	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
 	spin_unlock_bh(&adapter->mcc_lock);
+	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
 	return status;
 }
 
-- 
2.49.0

Re: [PATCH net] benet: fix BUG when creating VFs

[Nikolay Aleksandrov]

On 8/1/25 13:13, Michal Schmidt wrote:
> benet crashes as soon as SRIOV VFs are created:
> 
>  kernel BUG at mm/vmalloc.c:3457!
>  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
>  CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)
>  [...]
>  RIP: 0010:vunmap+0x5f/0x70
>  [...]
>  Call Trace:
>   <TASK>
>   __iommu_dma_free+0xe8/0x1c0
>   be_cmd_set_mac_list+0x3fe/0x640 [be2net]
>   be_cmd_set_mac+0xaf/0x110 [be2net]
>   be_vf_eth_addr_config+0x19f/0x330 [be2net]
>   be_vf_setup+0x4f7/0x990 [be2net]
>   be_pci_sriov_configure+0x3a1/0x470 [be2net]
>   sriov_numvfs_store+0x20b/0x380
>   kernfs_fop_write_iter+0x354/0x530
>   vfs_write+0x9b9/0xf60
>   ksys_write+0xf3/0x1d0
>   do_syscall_64+0x8c/0x3d0
> 
> be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.
> Fix it by freeing only after the lock has been released.
> 
> Fixes: 1a82d19ca2d6 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink")
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
>  drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
> index d730af4a50c7..bb5d2fa15736 100644
> --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> @@ -3856,8 +3856,8 @@ int be_cmd_set_mac_list(struct be_adapter *adapter, u8 *mac_array,
>  	status = be_mcc_notify_wait(adapter);
>  
>  err:
> -	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
>  	spin_unlock_bh(&adapter->mcc_lock);
> +	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
>  	return status;
>  }
>  

Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>

Re: [PATCH net] benet: fix BUG when creating VFs

[Jakub Kicinski]

On Fri,  1 Aug 2025 12:13:37 +0200 Michal Schmidt wrote:
> benet crashes as soon as SRIOV VFs are created:

>  err:
> -	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
>  	spin_unlock_bh(&adapter->mcc_lock);
> +	dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
>  	return status;
>  }
>  

Quick grep reveals an identical problem in be_cmd_get_phy_info() ?
Or is this bug size-sensitive ? I don't see the vunmap call..

Re: [PATCH net] benet: fix BUG when creating VFs

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri,  1 Aug 2025 12:13:37 +0200 you wrote:
> benet crashes as soon as SRIOV VFs are created:
> 
>  kernel BUG at mm/vmalloc.c:3457!
>  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
>  CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)
>  [...]
>  RIP: 0010:vunmap+0x5f/0x70
>  [...]
>  Call Trace:
>   <TASK>
>   __iommu_dma_free+0xe8/0x1c0
>   be_cmd_set_mac_list+0x3fe/0x640 [be2net]
>   be_cmd_set_mac+0xaf/0x110 [be2net]
>   be_vf_eth_addr_config+0x19f/0x330 [be2net]
>   be_vf_setup+0x4f7/0x990 [be2net]
>   be_pci_sriov_configure+0x3a1/0x470 [be2net]
>   sriov_numvfs_store+0x20b/0x380
>   kernfs_fop_write_iter+0x354/0x530
>   vfs_write+0x9b9/0xf60
>   ksys_write+0xf3/0x1d0
>   do_syscall_64+0x8c/0x3d0
> 
> [...]

Here is the summary with links:
  - [net] benet: fix BUG when creating VFs
    https://git.kernel.org/netdev/net/c/5a40f8af2ba1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net] benet: fix BUG when creating VFs

[Michal Schmidt]

On Tue, Aug 5, 2025 at 2:21 AM Jakub Kicinski <kuba@kernel.org> wrote:
> On Fri,  1 Aug 2025 12:13:37 +0200 Michal Schmidt wrote:
> > benet crashes as soon as SRIOV VFs are created:
>
> >  err:
> > -     dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
> >       spin_unlock_bh(&adapter->mcc_lock);
> > +     dma_free_coherent(&adapter->pdev->dev, cmd.size, cmd.va, cmd.dma);
> >       return status;
> >  }
> >
>
> Quick grep reveals an identical problem in be_cmd_get_phy_info() ?
> Or is this bug size-sensitive ? I don't see the vunmap call..

The call chain to the vunmap is:
dma_free_coherent -> dma_free_attrs -> iommu_dma_free ->
__iommu_dma_free -> dma_common_free_remap -> vunmap

I think the reason be_cmd_get_phy_info() does not cause a problem is
it uses dma_alloc_coherent(..., GFP_ATOMIC).
Then iommu_dma_alloc() does not go into the iommu_dma_alloc_remap() path.
The corresponding dma_free_coherent() then does not go into the
is_vmalloc_addr() branch in __iommu_dma_free().

Michal