Re: [PATCH 1/1] eal: correct memory ordering in MCS lock

[Wathsala Vithanage <wathsala.vithanage@arm.com>]

On 11/3/25 12:06, Konstantin Ananyev 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.

It’s really broken, because the release from lock() isn’t properly acquired
by the thread calling unlock(). This can lead to a situation where the 
unlock()
caller’s write to the locked field gets overwritten by the lock() 
caller’s write,
resulting in a potential deadlock.

This patch adds the missing synchronization edge, ensuring that all writes
made before the lock() caller updates prev->next are visible to the unlock()
caller once it reads me->next.