Re: [PATCH nf-next 0/4] netfilter: use skb_drop_reason in more places

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sat, Oct 12, 2024 at 05:54:48PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> 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.