netdev - Re: [PATCH net-next v5 2/2] net/mlx5: Expose SFs IRQs

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: <7b11bbd4-585f-4322-a5c0-93ff90100a88@nvidia.com>
Date: Wed, 29 May 2024 14:13:53 +0300
From: Shay Drori <shayd@...dia.com>
To: Parav Pandit <parav@...dia.com>, Przemek Kitszel
	<przemyslaw.kitszel@...el.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>, "kuba@...nel.org"
	<kuba@...nel.org>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"david.m.ertman@...el.com" <david.m.ertman@...el.com>
CC: "rafael@...nel.org" <rafael@...nel.org>, "ira.weiny@...el.com"
	<ira.weiny@...el.com>, "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>, "leon@...nel.org" <leon@...nel.org>, "Tariq
 Toukan" <tariqt@...dia.com>
Subject: Re: [PATCH net-next v5 2/2] net/mlx5: Expose SFs IRQs



On 28/05/2024 17:51, Parav Pandit wrote:
> 
>> From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>> Sent: Tuesday, May 28, 2024 8:18 PM
> 
> [..]
> 
>> mlx5_irq_get_index(least_loaded_irq)), pool->name,
>>>    			      mlx5_irq_read_locked(least_loaded_irq) /
>> MLX5_EQ_REFS_PER_IRQ);
>>>    unlock:
>>> +	if (mlx5_irq_pool_is_sf_pool(pool)) {
>>> +		ret =
>> auxiliary_device_sysfs_irq_add(mlx5_sf_coredev_to_adev(dev),
>>> +
>> mlx5_irq_get_irq(least_loaded_irq));
>>> +		if (ret)
>>> +			mlx5_core_err(dev, "Failed to create sysfs entry for irq
>> %d, ret = %d\n",
>>> +				      mlx5_irq_get_irq(least_loaded_irq), ret);
>>
>> you are handling the error by logging a message, then ignoring it this is clearly
>> not an ERROR, just a WARN or INFO.
>>
>>> +	}
>>>    	mutex_unlock(&pool->lock);
>>>    	return least_loaded_irq;
>>>    }
>>
>> [...]
> 
> I clearly remember discussing/reviewing this internally to error out.
> Without it, we didn’t add the entry, but we will try to remove it where the remove function does not expect an error.
> 
> Shay,
> Error unwinding should happen when fail to create the sysfs entry.


correct, will fix in next version