netdev - Re: Sleeping in atomic context with VLAN and netdev instance lock drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d7555a08d9c44ab89161c400119b3edf28043a74.camel@nvidia.com>
Date: Sat, 19 Jul 2025 10:23:21 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "stfomichev@...il.com" <stfomichev@...il.com>
CC: "kuba@...nel.org" <kuba@...nel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "sdf@...ichev.me" <sdf@...ichev.me>
Subject: Re: Sleeping in atomic context with VLAN and netdev instance lock
 drivers

On Tue, 2025-07-15 at 08:55 -0700, Stanislav Fomichev wrote:
> 
> Thanks for the report, I was looking at similar issue in [0] and for
> macsec I was thinking about the following:
> 
> diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> index 7edbe76b5455..4c75d1fea552 100644
> --- a/drivers/net/macsec.c
> +++ b/drivers/net/macsec.c
> @@ -3868,7 +3868,7 @@ static void macsec_setup(struct net_device
> *dev)
>  	ether_setup(dev);
>  	dev->min_mtu = 0;
>  	dev->max_mtu = ETH_MAX_MTU;
> -	dev->priv_flags |= IFF_NO_QUEUE;
> +	dev->priv_flags |= IFF_NO_QUEUE | IFF_UNICAST_FLT;
>  	dev->netdev_ops = &macsec_netdev_ops;
>  	dev->needs_free_netdev = true;
>  	dev->priv_destructor = macsec_free_netdev;
> 
> macsec has an ndo_set_rx_mode handler that propagates the uc list so
> not sure why it lacks IFF_UNICAST_FLT.
> 
> This is not a systemic fix, but I guess with the limited number of
> stacking devices, that should do? If that fixes the issue for you,
> I can send a patch..
> 
> 0:
> https://lore.kernel.org/netdev/686d55b4.050a0220.1ffab7.0014.GAE@google.com/

I tested, this works, thank you.
I guess avoiding nested calls requiring the instance lock while holding
the spinlock is one way of avoiding the problem. Looking forward to the
fix.

Thank you,
Cosmin.