On 3/7/2024 8:01 AM, Artemy Kovalyov wrote:
The initialization of the Memzone file-backed array ensures its
uniqueness by employing an exclusive lock. This is crucial because only
one primary process can exist per specific shm_id, which is further
protected by the exclusive EAL runtime configuration lock.


I think you meant to say "prefix", not "shm_id".

However, during the process closure, the exclusive lock on both the
fbarray and the configuration is not explicitly released. The
responsibility of releasing these locks is left to the generic quit
procedure. This can lead to a potential race condition when the
configuration is released before the fbarray.

To address this, we propose explicitly closing the memzone fbarray. This
ensures proper order of operations during process closure and prevents
any potential race conditions arising from the mismatched lock release
timings.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Artemy Kovalyov <artem...@nvidia.com>
---

I would suggest having a different Fixes: ID, because fbarrays were only added in 18.05 when we added dynamic memory support. I propose using this commit ID instead:

49df3db84883 ("memzone: replace memzone array with fbarray")

This is the first commit where memzones used fbarrays.

+void
+rte_eal_memzone_cleanup(void)
+{
+       struct rte_mem_config *mcfg;
+
+       mcfg = rte_eal_get_configuration()->mem_config;
+
+       if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+               rte_fbarray_destroy(&mcfg->memzones);
+       }

Nitpick: extraneous brackets, this is a one liner so they're not needed.

With changes above,

Acked-by: Anatoly Burakov <anatoly.bura...@intel.com>
--
Thanks,
Anatoly

Reply via email to