Received-SPF: pass (google.com: domain of linux-kernel+bounces-28927-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 17 Jan 2024 12:47:13 +0100
From: Florian Westphal <fw@strlen.de>
To: wangkeqi <wangkeqi_chris@163.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	wangkeqi <wangkeqiwang@didiglobal.com>,
	kernel test robot <oliver.sang@intel.com>, fengwei.yin@intel.com
Subject: Re: [PATCH net v2] connector: Change the judgment conditions for
 clearing proc_event_num_listeners
Message-ID: <20240117114713.GA11468@breakpoint.cc>
References: <20240116015753.209781-1-wangkeqi_chris@163.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240116015753.209781-1-wangkeqi_chris@163.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

wangkeqi <wangkeqi_chris@163.com> wrote:
> From: wangkeqi <wangkeqiwang@didiglobal.com>
> 
> 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 <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202401112259.b23a1567-oliver.sang@intel.com
> Fixes: c46bfba133 ("connector: Fix proc_event_num_listeners count not cleared")
> Signed-off-by: wangkeqi <wangkeqiwang@didiglobal.com>
> Cc: fengwei.yin@intel.com
> ---
>  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?