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.