[PATCH 1/1] eal: correct memory ordering in MCS lock
Wathsala Vithanage
wathsala.vithanage at arm.com
Mon Nov 3 20:13:37 CET 2025
On 11/3/25 12:48, Stephen Hemminger wrote:
> On Mon, 3 Nov 2025 18:06:05 +0000
> Konstantin Ananyev<konstantin.ananyev at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20251103/413af9f6/attachment.htm>
More information about the dev
mailing list