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

[Anjali Kulkarni]

> 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.
>> 
>> ANJALI> Yes, it is, but there does not seem a very clean way to do it
>> ANJALI> otherwise and I saw a check for protocol NETLINK_GENERIC just
>> ANJALI> below it, so used it for connector as well. There is no
>> ANJALI> release or free callback in the netlink_sock. Is it ok to add
>> ANJALI> it? There was another bug (for which I have not yet sent a
>> ANJALI> patch) in which, we need to decrement
>> ANJALI> proc_event_num_listeners, when client exits without calling
>> ANJALI> IGNORE, else that count again gets out of status of actual no
>> ANJALI> of listeners.   
>> 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.

> 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.
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.

Anjali