netdev - Re: traceability of wifi packet drops

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <abcf4b9aed8adad05841234dad103ced15f9bfb2.camel@sipsolutions.net>
Date:   Tue, 28 Mar 2023 09:37:43 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: traceability of wifi packet drops

On Mon, 2023-03-27 at 18:09 -0700, Jakub Kicinski wrote:
> > Anyone have any great ideas?
> 
> We need something that'd scale to more subsystems, so I don't think
> having all the definitions in enum skb_drop_reason directly is an
> option.

Fair enough.

> My knee jerk idea would be to either use the top 8 bits of the
> skb reason enum to denote the space. And then we'd say 0 is core
> 1 is wifi (enum ieee80211_rx_result) etc. Within the WiFi space 
> you can use whatever encoding you like.

Right. That's not _that_ far from what I proposed above, except you pull
the core out 

> On a quick look nothing is indexed by the reason directly, so no
> problems with using the high bits.

I think you missed he drop_reasons[] array in skbuff.c, but I guess we
could just not add these to the DEFINE_DROP_REASON() macro (and couldn't
really add them anyway).

The only user seems to be drop_monitor, which anyway checks the array
bounds (in the trace hit function.)

Or we change the design of this to actually have each subsystem provide
an array/a callback for their namespace, if the strings are important?
Some registration/unregistration might be needed for modules, but that
could be done.

> Option #2 is to add one main drop reason called SKB_DROP_REASON_MAC80211
> and have a separate tracepoint which exposes the detailed wifi
> reason and any necessary context. mac80211 would then have its own
> wrapper around kfree_skb_reason() which triggers the tracepoint.

Yeah, I considered doing that with just the line number, but who knows
what people might want to use this for in the end, so that's not a great
idea either I guess :-)

I would prefer the version with the drop reasons, since then also you
only have to worry about one tracepoint.

johannes