Re: [PATCH 10/11] wifi: mac80211: avoid tailroom accounting on new key installation

["Luka Gejak" <luka.gejak@linux.dev>]

Hi Johannes,

On Tue Oct 13, 2026 at 6:22 PM UTC, Johannes Berg wrote:
> This is well and all, but I'm starting to think we should just not do
> this. Given that SW crypto really should be the slow-path, I think we
> can instead simply remove the RCU sync *completely*, and accept that in
> the race case, the (SW) crypto path may have to expand tailroom (and
> might drop a frame if allocation fails).
>
> That's far simpler, no need to add the RX_ONLY flag I did in patch 11
> etc., ultimately instead of adding code it ends up removing some, since
> we can also get rid of the dec_tailroom_needed_wk and all that.
>
> Thoughts?

Agreed, the counter only exists to avoid synchronize_net(). Two things I
would want in the same series though, because "expand, or maybe drop a
frame" is not quite what the code does today.

The data crypto paths warn and drop rather than expand. tkip, ccmp and
gcmp all WARN_ON(skb_tailroom(skb) < tail) and return -1, and
ieee80211_tx_h_michael_mic_add() returns TX_DROP. So either those grow a
pskb_expand_head fallback, or the WARN_ONs become plain checks.

And the counter is also the cloned skb unshare trigger in
ieee80211_skb_resize(). Without it a header released clone with slack at
the tail skips the unshare, and software crypto then writes the MIC into
memory it does not own alone, which skb_tailroom() would not catch. An
unshare in the encrypt path would.

With that the counter is only an optimisation, so no objection from me.

Best regards,
Luka Gejak