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
| ||
|
Message-ID: <20230328155826.38e9e077@kernel.org> Date: Tue, 28 Mar 2023 15:58:26 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Johannes Berg <johannes@...solutions.net> Cc: Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, linux-wireless@...r.kernel.org Subject: Re: traceability of wifi packet drops On Tue, 28 Mar 2023 09:37:43 +0200 Johannes Berg wrote: > > 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 Thinking about it again, maybe yours is actually cleaner. Having the subsystem reason on the top bits, I mean. That way after masking the specific bits out the lower bits can still provide a valid "global" drop reason. The UNUSABLE vs MONITOR bits I'd be tempted to put in the "global" reason, but maybe that's not a great idea given Eric's concern :) > > 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. Right, drop monitor is good ol' kernel code, we can make it do whatever we want. I was worried that tracing / BPF may tie our hands but they support sparse enums just fine.
Powered by blists - more mailing lists