From: wangkeqi <[email protected]>
It is inaccurate to judge whether proc_event_num_listeners is
cleared by cn_netlink_send_mult returning -ESRCH.
In the case of stress-ng netlink-proc, -ESRCH will always be returned,
because netlink_broadcast_filtered will return -ESRCH,
which may cause stress-ng netlink-proc performance degradation.
Therefore, the judgment condition is modified to whether
there is a listener.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-lkp/[email protected]
Fixes: c46bfba133 ("connector: Fix proc_event_num_listeners count not cleared")
Signed-off-by: wangkeqi <[email protected]>
Cc: [email protected]
---
drivers/connector/cn_proc.c | 6 ++++--
drivers/connector/connector.c | 6 ++++++
include/linux/connector.h | 1 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 3d5e6d705..b09f74ed3 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -108,8 +108,10 @@ static inline void send_msg(struct cn_msg *msg)
filter_data[1] = 0;
}
- if (cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
- cn_filter, (void *)filter_data) == -ESRCH)
+ if (netlink_has_listeners(get_cdev_nls(), CN_IDX_PROC))
+ cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
+ cn_filter, (void *)filter_data);
+ else
atomic_set(&proc_event_num_listeners, 0);
local_unlock(&local_event.lock);
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 7f7b94f61..1b2cd410e 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -129,6 +129,12 @@ int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group,
}
EXPORT_SYMBOL_GPL(cn_netlink_send);
+struct sock *get_cdev_nls(void)
+{
+ return cdev.nls;
+}
+EXPORT_SYMBOL_GPL(get_cdev_nls);
+
/*
* Callback helper - queues work and setup destructor for given data.
*/
diff --git a/include/linux/connector.h b/include/linux/connector.h
index cec2d99ae..255466aea 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -127,6 +127,7 @@ int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid,
*/
int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 group, gfp_t gfp_mask);
+struct sock *get_cdev_nls(void);
int cn_queue_add_callback(struct cn_queue_dev *dev, const char *name,
const struct cb_id *id,
void (*callback)(struct cn_msg *, struct netlink_skb_parms *));
--
2.27.0
wangkeqi <[email protected]> wrote:
> From: wangkeqi <[email protected]>
>
> It is inaccurate to judge whether proc_event_num_listeners is
> cleared by cn_netlink_send_mult returning -ESRCH.
> In the case of stress-ng netlink-proc, -ESRCH will always be returned,
> because netlink_broadcast_filtered will return -ESRCH,
> which may cause stress-ng netlink-proc performance degradation.
> Therefore, the judgment condition is modified to whether
> there is a listener.
>
> Reported-by: kernel test robot <[email protected]>
> Closes: https://lore.kernel.org/oe-lkp/[email protected]
> Fixes: c46bfba133 ("connector: Fix proc_event_num_listeners count not cleared")
> Signed-off-by: wangkeqi <[email protected]>
> Cc: [email protected]
> ---
> drivers/connector/cn_proc.c | 6 ++++--
> drivers/connector/connector.c | 6 ++++++
> include/linux/connector.h | 1 +
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
> index 3d5e6d705..b09f74ed3 100644
> --- a/drivers/connector/cn_proc.c
> +++ b/drivers/connector/cn_proc.c
> @@ -108,8 +108,10 @@ static inline void send_msg(struct cn_msg *msg)
> filter_data[1] = 0;
> }
>
> - if (cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
> - cn_filter, (void *)filter_data) == -ESRCH)
> + if (netlink_has_listeners(get_cdev_nls(), CN_IDX_PROC))
> + cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
> + cn_filter, (void *)filter_data);
> + else
> atomic_set(&proc_event_num_listeners, 0);
How is that serialized vs. cn_proc_mcast_ctl?
1. netlink_has_listeners() returns false
2. other core handles PROC_CN_MCAST_LISTEN, atomic_inc called
3. This core (re)sets counter to 0, but there are listeners, so
all functions that do
if (atomic_read(&proc_event_num_listeners) < 1)
return;
will not get enabled/remain disabled.
Probably better to add cn_netlink_has_listeners() function
and use that instead of the (inaccurate) counter?
If cn_netlink_has_listeners() is used instead of proc_event_num_listeners, I think proc_event_num_listeners will be completely meaningless.
I read the code and found that there is nothing wrong with cn_netlink_has_listeners as a judgment of whether to send msg.
sock_close will update the listeners. The previous proc_event_num_listeners count was wrong, making it meaningless.
But if I change it to cn_netlink_has_listeners, will it affect some low-probability scenarios?
At 2024-01-17 19:47:13, "Florian Westphal" <[email protected]> wrote:
>wangkeqi <[email protected]> wrote:
>> From: wangkeqi <[email protected]>
>>
>> It is inaccurate to judge whether proc_event_num_listeners is
>> cleared by cn_netlink_send_mult returning -ESRCH.
>> In the case of stress-ng netlink-proc, -ESRCH will always be returned,
>> because netlink_broadcast_filtered will return -ESRCH,
>> which may cause stress-ng netlink-proc performance degradation.
>> Therefore, the judgment condition is modified to whether
>> there is a listener.
>>
>> Reported-by: kernel test robot <[email protected]>
>> Closes: https://lore.kernel.org/oe-lkp/[email protected]
>> Fixes: c46bfba133 ("connector: Fix proc_event_num_listeners count not cleared")
>> Signed-off-by: wangkeqi <[email protected]>
>> Cc: [email protected]
>> ---
>> drivers/connector/cn_proc.c | 6 ++++--
>> drivers/connector/connector.c | 6 ++++++
>> include/linux/connector.h | 1 +
>> 3 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
>> index 3d5e6d705..b09f74ed3 100644
>> --- a/drivers/connector/cn_proc.c
>> +++ b/drivers/connector/cn_proc.c
>> @@ -108,8 +108,10 @@ static inline void send_msg(struct cn_msg *msg)
>> filter_data[1] = 0;
>> }
>>
>> - if (cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
>> - cn_filter, (void *)filter_data) == -ESRCH)
>> + if (netlink_has_listeners(get_cdev_nls(), CN_IDX_PROC))
>> + cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
>> + cn_filter, (void *)filter_data);
>> + else
>> atomic_set(&proc_event_num_listeners, 0);
>
>How is that serialized vs. cn_proc_mcast_ctl?
>
>1. netlink_has_listeners() returns false
>2. other core handles PROC_CN_MCAST_LISTEN, atomic_inc called
>3. This core (re)sets counter to 0, but there are listeners, so
> all functions that do
>
> if (atomic_read(&proc_event_num_listeners) < 1)
> return;
>
>will not get enabled/remain disabled.
>
>Probably better to add cn_netlink_has_listeners() function
>and use that instead of the (inaccurate) counter?
wangkeqi <[email protected]> wrote:
>
> If cn_netlink_has_listeners() is used instead of proc_event_num_listeners, I think proc_event_num_listeners will be completely meaningless.?
> I read the code and found that there is nothing wrong with cn_netlink_has_listeners as a judgment of whether to send msg.?
> sock_close will update the listeners.?The previous proc_event_num_listeners count was wrong, making it meaningless.?
> But if I change it to cn_netlink_has_listeners, will it affect some low-probability scenarios?
Please avoid top-posting on netdev mailing list.
Yes, thats what I meant, replace proc_event_num_listeners.
I do not know what a 'low-probability scenarios' is.