linux-kernel - Re: [RFC PATCH v2 wireless-next 2/3] wifi: mac80211: Correctly init MLO link in ieee80211_8023

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: <cdc17da890c87dc2dd6e521197594f1be1eb0a03.camel@sipsolutions.net>
Date: Tue, 22 Jul 2025 14:25:33 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Remi Pommarel <repk@...plefau.lt>, linux-wireless@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 wireless-next 2/3] wifi: mac80211: Correctly init
 MLO link in ieee80211_8023_xmit()

On Fri, 2025-07-11 at 12:03 +0200, Remi Pommarel wrote:
> The IEEE80211_TX_CTRL_MLO_LINK info is the only part of
> ieee80211_tx_control where a 0 value has a specific meaning. Thus this
> should always be initialized with IEEE80211_LINK_UNSPECIFIED if there is
> no MLO link information associated with the skb, even using when 802.11
> hw encap offloading.

I'm not against this and the patch looks fine, but I guess I'm surprised
it even matters to anyone. The encap offloading fundamentally requires
that the driver do more work to identify the destination STA, and then
anyway the link is picked by driver/FW? Or is there a case of encap
offload with _multicast_?

Anyway, looks OK and just sets a few bits that I feel like it's weird
that they're even used, so doesn't matter :)

johannes