Re: lockup and kernel panic in linux-next-202505{09,12} when compiled with clang

[Johannes Berg <johannes@sipsolutions.net>]

+ linux-wireless

On Wed, 2025-05-14 at 09:32 +0000, Bert Karwatzki wrote:

> Then I reapplied commit 76a853f86c97 hunk by hunk and found the one hunk that
> causes the problem:
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 3e751dd3ae7b..63df21228029 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -4648,8 +4648,7 @@ static void ieee80211_8023_xmit(struct
> ieee80211_sub_if_data *sdata,
>                         memcpy(IEEE80211_SKB_CB(seg), info, sizeof(*info));
>         }
> 
> -       if (unlikely(skb->sk &&
> -                    skb_shinfo(skb)->tx_flags & SKBTX_WIFI_STATUS)) {
> +       if (unlikely(skb->sk && sock_flag(skb->sk, SOCK_WIFI_STATUS))) {
>                 info->status_data = ieee80211_store_ack_skb(local, skb,
>                                                             &info->flags, NULL);
>                 if (info->status_data)

I think it crashed later on the status, but this inserts the skb into
the IDR so the status can pick it up to return the status and afaict
_that's_ where it crashed.

Still I don't really know what could go wrong? The (copied) skb should
still have been keeping the socket alive.

> This is enough to cause a kernel panic when compiled with clang (clang-19.1.7
> from debian sid). Compiling the same kernel with gcc (gcc-14.2.0 from debian
> sid) shows no problem.

Right, even stranger. But I can't even say you should look at this place
(which inserts) or the other (which takes it out again and crashed) to
compare the code :-/


johannes