On Sat, Oct 12, 2024 at 05:54:48PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > Or do you mean using a different macro that always sets EPERM? > > > > Maybe remove SKB_DROP_REASON_NETFILTER_DROP from macro, so line is > > shorter? > > > > NF_DROP_REASON(pkt->skb, -EPERM) > > > > And add a new macro for br_netfilter NF_BR_DROP_REASON which does not > > always sets SKB_DROP_REASON_NETFILTER_DROP? (Pick a better name for > > this new macro if you like). > > NF_DROP_REASON is already in the tree and currently most users use > something other than SKB_DROP_REASON_NETFILTER_DROP. > > I did not yet add new enum values or a dedicated nf namespace > (enum skb_drop_reason_subsys), because I did not see a reason and > wasn't sure if we'd need sub-subsystems (nf_tables, conntrack, nat, > whatever). Does this mean values exposed through tracing infrastructure can change or these are part of uapi? From what I read from you, I understand it is possible to change SKB_DROP_REASON_NETFILTER_DROP to a more specific sub-subsystem tag in the future without issues. > If you like, I can add NF_FREE_SKB(skb, errno) and rework this > set to use that? Not strong about this. I was exploring if it should be possible to remove (repetitive) information in the code that can be assumed to be implicit, I still like the word "REASON" in the macro for grepping. I think we can just move on with this series as-is if you prefer and add new macros incrementally to refine.
