On 11/3/25 12:48, Stephen Hemminger wrote:
> On Mon, 3 Nov 2025 18:06:05 +0000
> Konstantin Ananyev<konstantin.ananyev@huawei.com> wrote:
>
>>> On 11/3/25 11:07, Stephen Hemminger wrote:
>>>> On Mon, 3 Nov 2025 09:12:39 -0600
>>>> Wathsala Vithanage<wathsala.vithanage@arm.com> wrote:
>>>>   
>>>>> MCS lock is broken, it's just a matter of time it will run into a deadlock.
>>>>>
>>>>> drivers/dma/cnxk is a user of MCS lock.
>>>> I am surprised that a driver would use mcslock.
>>>> MCSlock is targeted at case of large number of CPU's with lots of contention.
>>>> It will likely be slower than spinlock or ticketlock for the use case of driver.
>>> It appears in |drivers/dma/cnxk/cnxk_dmadev_fp.c|, perhaps the
>>> maintainer can clarify.
>>>    
>> If MCS lock is really broken, it needs to be fixed anyway.
>> It might be used by other third-party libs/apps that do use on DPDK.
> 100% agree it must be fixed.
> It would be good to have test or static analysis tool that could validate all the lock types.
Looked at seqlock; it seems correct.

Herd7 has been useful, but it's not a static analysis tool. It requires 
identifying a trouble
spot manually and then writing a litmus test to test the hypothesis.