[PATCH v2 3/4] timer: fix function to stop all timers
Naga Harish K, S V
s.v.naga.harish.k at intel.com
Thu Aug 11 17:42:37 CEST 2022
Hi Gabe,
> -----Original Message-----
> From: Carrillo, Erik G <erik.g.carrillo at intel.com>
> Sent: Thursday, August 11, 2022 1:00 AM
> To: Naga Harish K, S V <s.v.naga.harish.k at intel.com>
> Cc: dev at dpdk.org; stable at dpdk.org
> Subject: RE: [PATCH v2 3/4] timer: fix function to stop all timers
>
> Hi Harish,
>
> > -----Original Message-----
> > From: Naga Harish K, S V <s.v.naga.harish.k at intel.com>
> > Sent: Wednesday, August 10, 2022 2:10 AM
> > To: Carrillo, Erik G <erik.g.carrillo at intel.com>
> > Cc: dev at dpdk.org; stable at dpdk.org
> > Subject: [PATCH v2 3/4] timer: fix function to stop all timers
> >
> > There is a possibility of deadlock in this API, as same spinlock is
> > tried to be acquired in nested manner.
> >
> > In timer_del function, if the previous owner and current owner lcore
> > are
>
> It might be clearer to say something like:
>
> "If the lcore that is stopping the timer is different from the lcore that owns
> the timer, the timer list lock is acquired in timer_del(), even if local_is_locked
> is true. Because the same lock was already acquired in rte_timer_stop_all(),
> the thread will hang."
>
Incorporated the commit message in v3 version of the patch
> Thanks,
> Erik
>
> > different, the lock is tried to be acquired even though the same lock
> > is already acquired by the caller of timer_del function.
> >
> > This patch removes the acquisition of nested locking.
> >
> > Fixes: 821c51267bcd63a ("timer: add function to stop all timers in a
> > list")
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k at intel.com>
> > ---
More information about the dev
mailing list