On Wed, Sep 25, 2024 at 07:51:54PM +0200, Florian Westphal wrote: > Phil Sutter <phil@xxxxxx> wrote: > > > This relies on implicit NFNL_CB_UNSPEC == 0 and nfnetlink > > > bailing out whe NFT_MSG_NEWDEV appears in a netlink message > > > coming from userspace. > > > > I guess with 'implicit NFNL_CB_UNSPEC == 0' you mean the extra > > nf_tables_cb array fields' 'type' value being 0 (nfnetlink.h explicitly > > defines NFNL_CB_UNSPEC value as 0). I don't see the connection here > > though, probably I miss nfnetlink_rcv_msg() relying on that field value > > or so. > > I should have been more clear, I was wondering if we need/want > an -EOPNOTSUPP stub callback rather than reliance of nfnetlink to > detect it. Sure, I got your point. The NFNL_CB_UNSPEC reference was just a bit confusing. > > I see at least NFNL_MSG_ACCT_OVERQUOTA missing from nfnl_acct_cb. The > > former was introduced in 2014. May I claim grandfathering? ;) > > I guess it just means "no we don't worry about it". Maybe. At least we rely upon the behaviour for a while now, possibly by accident. We could get rid of the nc->call != NULL check by assigning such stub in nfnetlink_subsys_register(). OK, technically it would just move the NULL check. Without such stunts, nfnetlink_rcv_msg() would have to remain as-is to cover for future users with holes, right? Cheers, Phil
