[dpdk-dev] [PATCH v3 1/1] timer: fix resource leak in finalize

Thomas Monjalon thomas at monjalon.net
Sat Jul 6 00:06:24 CEST 2019


05/07/2019 19:22, Anatoly Burakov:
> Currently, whenever timer library is initialized, the memory
> is leaked because there is no telling when primary or secondary
> processes get to use the state, and there is no way to
> initialize/deinitialize timer library state without race
> conditions [1] because the data itself must live in shared memory.
> 
> Add a spinlock to the shared mem config to have a way to
> exclusively initialize/deinitialize the timer library without
> any races, and implement the synchronization mechanism based
> on this lock in the timer library.
> 
> Also, update the API doc. Note that the behavior of the API
> itself did not change - the requirement to call init in every
> process was simply not documented explicitly.
> 
> Fixes: c0749f7096c7 ("timer: allow management in shared memory")
> 
> [1] See the following email thread:
> https://mails.dpdk.org/archives/dev/2019-May/131498.html
> 
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo at intel.com>
> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
> Acked-by: Erik Gabriel Carrillo <erik.g.carrillo at intel.com>
> Reviewed-by: David Marchand <david.marchand at redhat.com>

Applied, thanks





More information about the dev mailing list