netdev - Re: [PATCH net-next,v2] bonding: use WARN_ON_ONCE 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZVNJBEuJw+rT/Biq@Laptop-X1>
Date: Tue, 14 Nov 2023 18:16:36 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Zhengchao Shao <shaozhengchao@...wei.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, j.vosburgh@...il.com,
	andy@...yhouse.net, weiyongjun1@...wei.com, yuehaibing@...wei.com
Subject: Re: [PATCH net-next,v2] bonding: use WARN_ON_ONCE instead of BUG in
 alb_upper_dev_walk

On Tue, Nov 14, 2023 at 05:18:29PM +0800, Zhengchao Shao 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.
> Using WARN_ON_ONCE here is to avoid spamming the log if there's a lot of
> macvlans above the bond.
> 
> Signed-off-by: Zhengchao Shao <shaozhengchao@...wei.com>
> ---
> v2: use WARN_ON_ONCE instead of WARN_ON
> ---
>  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..a7bad0fff8cb 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_ONCE(1);
> +			return 0;

Return 0 for an error looks weird. Should we keep walking the list if
allocate "tags" failed?

Thanks
Hangbin