Re: [PATCH v2] eal: fix memory initialization deadlock

2023-09-05 Thread David Marchand
On Tue, Sep 5, 2023 at 11:05 AM Artemy Kovalyov wrote: > > > > + /* memory_hotplug_lock is taken in rte_eal_init(), so it's > > > +* safe to call thread-unsafe version. > > > +*/ > > > > Nit: the lock is really taken in rte_eal_memory_init(). > > Probably "The l

RE: [PATCH v2] eal: fix memory initialization deadlock

2023-09-05 Thread Artemy Kovalyov
> > + /* memory_hotplug_lock is taken in rte_eal_init(), so it's > > +* safe to call thread-unsafe version. > > +*/ > > Nit: the lock is really taken in rte_eal_memory_init(). > Probably "The lock is held during initialization, so..." > would more robust against

Re: [PATCH v2] eal: fix memory initialization deadlock

2023-09-05 Thread Dmitry Kozlyuk
2023-09-04 11:24 (UTC+0300), Artemy Kovalyov: > diff --git a/lib/eal/common/eal_common_dynmem.c > b/lib/eal/common/eal_common_dynmem.c > index bdbbe233a0..0d5da40096 100644 > --- a/lib/eal/common/eal_common_dynmem.c > +++ b/lib/eal/common/eal_common_dynmem.c > @@ -251,7 +251,10 @@ eal_dynmem_hugep

[PATCH v2] eal: fix memory initialization deadlock

2023-09-04 Thread Artemy Kovalyov
The issue arose due to the change in the DPDK read-write lock implementation. That change added a new flag, RTE_RWLOCK_WAIT, designed to prevent new read locks while a write lock is in the queue. However, this change has led to a scenario where a recursive read lock, where a lock is acquired twice