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 <[email protected]> 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.
