Re: [PATCH v1 2/5] connector/cn_proc: Add filtering to fix some bugs

[Jakub Kicinski]

On Wed, 15 Mar 2023 19:08:34 +0000 Anjali Kulkarni wrote:
> > On Mar 14, 2023, at 9:59 PM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
> > 
> > On Tue, 14 Mar 2023 02:32:13 +0000 Anjali Kulkarni wrote:  
> >> This is clearly a layering violation, right?
> >> Please don't add "if (family_x)" to the core netlink code.
> >> The other option is to add a flag in netlink_sock, something like
> >> NETLINK_F_SK_USER_DATA_FREE, which will free the sk_user_data, if
> >> this flag is set. But it does not solve the above scenario.  
> > 
> > Please fix your email setup, it's really hard to read your replies.
> >   
> 
> I have changed my email client, let me know if this does not fix the issue you see.

Quite a bit better, thanks!

> > There is an unbind callback, and a notifier. Can neither of those 
> > be made to work? ->sk_user_data is not a great choice of a field,
> > either, does any other netlink family use it this way?
> > Adding a new field for family use to struct netlink_sock may be better.  
> 
> The unbind call will not work because it is for the case of adding and deleting group memberships and hence called from netlink_setsockopt() when  NETLINK_DROP_MEMBERSHIP option is given. We would not be able to distinguish between the drop membership & release cases.
> The notifier call seems to be for blocked clients? Am not sure if the we need to block/wait on this call to be notified to free/release. Also, the API does not pass in struct sock to free what we want, so we will need to change that everywhere it is currently used.

I think that adding the new release callback is acceptable.
I haven't seen your v2 before replying.

> As for using sk_user_data - this field seems to be used by different applications in different ways depending on how they need to use data. If we use a new field in netlink_sock, we would need to add a new API function to allocate this member, similar to release, because it seems you cannot access netlink_sock outside of af_netlink, or at least I do not see any current access to it, and functions like nlk_sk are static. Also, if we add an allocation function, we won’t know the first time the client sends it’s data (we need to know “initial” in the patches), so we will need to add a new field in the socket to indicate first access or add a lot more infrastructure in cn_proc to store each client’s information.

Alright, I guess we can risk the sk_user_data, and see if anything
explodes. Normally higher protocol wraps the socket structure in its
own structure and the sk_user_data pointer is for an in-kernel user
of the socket (i.e. in kernel client). But "classic netlink" is all
legacy code (new subsystem use the generic netlink overlay) so trying
to decode now why things are the way they are and fixing the structure
would be a major effort :(