Thread (16 messages) 16 messages, 3 authors, 2023-04-01

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

From: Anjali Kulkarni <hidden>
Date: 2023-03-14 02:32:41
Also in: lkml

-int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 group, gfp_t gfp_mask);
+int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid,
+                      u32 group, gfp_t gfp_mask,
+                      int (*filter)(struct sock *dsk, struct sk_buff *skb,
+                                    void *data),
+                      void *filter_data);
kdoc needs to be extended
ANJALI> Thanks, will update in next revision.
-
+             if (sk->sk_protocol == NETLINK_CONNECTOR) {
+                     if (test_bit(CN_IDX_PROC - 1, nlk->groups)) {
+                             kfree(sk->sk_user_data);
+                             sk->sk_user_data = NULL;
+                     }
+             }
               for (i = 0; i < nlk->ngroups; i++)
                       if (test_bit(i, nlk->groups))
                               nlk->netlink_unbind(sock_net(sk), i + 1);
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 otherwise and I saw a check for protocol NETLINK_GENERIC just below it, so used it for connector as well. There is no release or free callback in the netlink_sock. Is it ok to add it? There was another bug (for which I have not yet sent a patch) in which, we need to decrement proc_event_num_listeners, when client exits without calling IGNORE, else that count again gets out of status of actual no 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.
.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help