netdev - Re: [PATCH v3 net-next 3/3] amd-xgbe: use smn functions to avoid race

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: <72d8ab78-4e61-ba13-2abe-dfe988dd511f@amd.com>
Date: Fri, 15 Dec 2023 08:35:47 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Raju Rangoju <Raju.Rangoju@....com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, Shyam-sundar.S-k@....com
Subject: Re: [PATCH v3 net-next 3/3] amd-xgbe: use smn functions to avoid race

On 12/14/23 22:35, Raju Rangoju wrote:
> 
> 
> On 12/12/2023 9:08 PM, Tom Lendacky wrote:
>> On 12/11/23 23:37, Raju Rangoju wrote:
>>> Some of the ethernet add-in-cards have dual PHY but share a single MDIO
>>> line (between the ports). In such cases, link inconsistencies are
>>> noticed during the heavy traffic and during reboot stress tests.
>>>
>>> So, use the SMN calls to avoid the race conditions.
>>
>> So this patch replaces all the PCI accesses you added in patch #2, so 
>> why not just do this from the start?
> 
> Yes, that is correct. It was done to maintain the history and that will be 
> reference as to why SMN is used over regular PCI accesses in this case.

Seems unnecessary to me. Adding a comment in the commit log and the code 
that states why SMN is used instead of PCI and how it fixes the race 
condition would be enough. Your call... but since patch #2 enables the 
device, this could cause a bisect issue.

Thanks,
Tom

>