netdev - Re: [PATCH net-next,v3] bonding: use WARN_ON instead of BUG in alb_upper_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d0803dc1-8013-5898-5788-464d7b000f46@huawei.com>
Date: Thu, 16 Nov 2023 21:58:04 +0800
From: shaozhengchao <shaozhengchao@...wei.com>
To: Jay Vosburgh <jay.vosburgh@...onical.com>, Simon Horman <horms@...nel.org>
CC: Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <andy@...yhouse.net>, <weiyongjun1@...wei.com>,
	<yuehaibing@...wei.com>
Subject: Re: [PATCH net-next,v3] bonding: use WARN_ON instead of BUG in
 alb_upper_dev_walk



On 2023/11/16 4:34, Jay Vosburgh wrote:
> Simon Horman <horms@...nel.org> wrote:
> 
>> On Wed, Nov 15, 2023 at 03:22:39PM +0100, Jiri Pirko wrote:
>>> Wed, Nov 15, 2023 at 12:55:37PM CET, shaozhengchao@...wei.com wrote:
>>>> If failed to allocate "tags" or could not find the final upper device from
>>>> start_dev's upper list in bond_verify_device_path(), only the loopback
>>>> detection of the current upper device should be affected, and the system is
>>>> no need to be panic.
>>>>
>>>> Signed-off-by: Zhengchao Shao <shaozhengchao@...wei.com>
>>>> ---
>>>> v3: return -ENOMEM instead of zero to stop walk
>>>> v2: use WARN_ON_ONCE instead of WARN_ON
>>>
>>> Yet the WARN_ON is back :O
>>
>> Hi Jiri,
>>
>> I think the suggestion was to either:
>>
>> 1. WARN_ON_ONCE(); return 0;      <= this was v2
>> 2. WARN_ON(); return -ESOMETHING; <= this is v3
>> (But not, WARN_ON(); return 0;    <= this was v1)
>>
>> And after v2 it was determined that the approach taken here in v3 is
>> preferred.
>>
>> So I think this patch is consistent with the feedback given by Jay
>> in his reviews so far.
> 
> 	Sigh, the more I look the more complicated this gets.
> 	
> 	Anyway, I was previously thinking we're ok with WARN_ON if the
> return is non-zero to terminate the device walk.  The bond itself will
> automatically call alb_upper_dev_walk at most once per second.
> 
> 	However, user space could do something like continuously change
> the MAC address of the bond or initiate a failover in order to trigger a
> call to alb_upper_dev_walk.  This won't be rate limited, and if the
> allocations there repeatedly fail, it would always trigger the WARN_ON.
> 
Yes, it will be bad.
> 	So, I'm thinking now that instead of WARN_anything, we should
> instead use something like
> 
> net_err_ratelimited("%s: %s: allocation failure\n", start_dev->name, __func__);
> 
> 	in bond_verify_device_path, and alb_upper_dev_walk doesn't do
> any WARN at all, and returns failure (non-zero).
> 	
> 	This is consistent with other similar allocation failures.
> 
Maybe you are right here. Thanks

Zhengchao Shao
> 	-J
> 
>>>> ---
>>>> drivers/net/bonding/bond_alb.c | 6 ++++--
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>>>> index dc2c7b979656..21f1cb8e453b 100644
>>>> --- a/drivers/net/bonding/bond_alb.c
>>>> +++ b/drivers/net/bonding/bond_alb.c
>>>> @@ -984,8 +984,10 @@ static int alb_upper_dev_walk(struct net_device *upper,
>>>> 	 */
>>>> 	if (netif_is_macvlan(upper) && !strict_match) {
>>>> 		tags = bond_verify_device_path(bond->dev, upper, 0);
>>>> -		if (IS_ERR_OR_NULL(tags))
>>>> -			BUG();
>>>> +		if (IS_ERR_OR_NULL(tags)) {
>>>> +			WARN_ON(1);
>>>> +			return -ENOMEM;
>>>> +		}
>>>> 		alb_send_lp_vid(slave, upper->dev_addr,
>>>> 				tags[0].vlan_proto, tags[0].vlan_id);
>>>> 		kfree(tags);
>>>> -- 
>>>> 2.34.1
>>>>
>>>>
>>>
>>
> 
> ---
> 	-Jay Vosburgh, jay.vosburgh@...onical.com