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

[Anjali Kulkarni <anjali.k.kulkarni@oracle.com>]

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

Thanks, so I will wait for your comments on v2 before sending updated patch.

> 
>> 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 :(

Ok, thanks!