Re: iw scan hangs in netlink ENOBUFS loop with kernel 6.6.99+

On Tue, 21 Jul 2026, Thorsten Leemhuis wrote:

> On 7/14/26 00:37, Peter Astrand wrote:
> > 
> > kernel 6.6.y
> > iw 6.7
> > libnl-genl-3-200 3.9.0
> > mac80211_hwsim
> > 
> > With kernel 6.6.99 and later, "iw dev <device> scan" sometimes hangs in 
> > busy loop:
> 
> Thanks for the report. We need to rule out if this is a 6.6.y specific
> problem (like a broken or incomplete backport) or something general.
> Could you please check if 7.2-rc is affected as well? Testing 6.18.y
> might help, too, if it's easy for you to try. Maybe switching to that
> might be the easies way to resolve the problem and a good idea in
> general, as explained here:
> http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

Platform is NXP imx6ull. Forgot to mention that we are actually running 
https://github.com/Freescale/linux-fslc/tree/6.6-2.2.x-imx rather than 
upstream kernel. No changes to net/netlink though.

We cannot easily test with 7.X, but I have tested 
https://github.com/Freescale/linux-fslc/tree/6.18-2.0.x-imx and can 
reproduce the same problem; this is 6.18.20. strace output is similar:

recvmsg(3, {msg_namelen=12}, 0)         = -1 ENOBUFS (No buffer space available)
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{nlmsg_len=48, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0, nlmsg_seq=2510255223, nlmsg_pid=1468011032}, {error=-ENOBUFS, msg=[{nlmsg_len=28, nlmsg_type=0x1b /* NLMSG_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK|0x300, nlmsg_seq=2510255223, nlmsg_pid=1468011032}, "\x20\x00\x00\x00\x08\x00\x03\x00\x0d\x00\x00\x00"]}], iov_len=16384}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 48

Br,
Peter


> 
> Ciao, Thorsten
> > recvmsg(3, {msg_namelen=12}, 0)         = -1 ENOBUFS (No buffer space available)
> > recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 
> > msg_namelen=12, msg_iov=[{iov_base=[{nlmsg_len=48, nlmsg_type=NLMSG_ERROR, 
> > nlmsg_flags=0, nlmsg_seq=2511084235, nlmsg_pid=-1866444344}, 
> > {error=-ENOBUFS, msg=[{nlmsg_len=28, nlmsg_type=0x18 /* NLMSG_??? */, 
> > nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK|0x300, nlmsg_seq=2511084235, 
> > nlmsg_pid=-1866444344}, 
> > "\x20\x00\x00\x00\x08\x00\x03\x00\x0e\x00\x00\x00"]}], iov_len=16384}], 
> > msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 48
> > 
> > This issue appears with kernel 6.6.99 and later, even latest version 
> > 6.6.144. 
> > 
> > If I revert these commits:
> > 
> > 346c820ef513 netlink: avoid infinite retry looping in netlink_unicast()
> > c31ee1695b6d netlink: make sure we allow at least one dump skb
> > ce2ac2e46719 netlink: Fix rmem check in netlink_broadcast_deliver().
> > 55baecb9eb90 netlink: Fix wraparounds of sk->sk_rmem_alloc.
> > 
> > ...then 6.6.144 works fine as well. Seems like there is a regression here. 
> > Any ideas? 
> > 
> > Br,
> > Peter Astrand
> > 
> 
> 
>