lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1407142340170.24854@nanos>
Date:	Mon, 14 Jul 2014 23:42:53 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Lai Jiangshan <laijs@...fujitsu.com>
cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1 V2] workqueue: remove the del_timer_sync()s in
 maybe_create_worker()

On Tue, 15 Jul 2014, Lai Jiangshan wrote:
> On 07/14/2014 11:33 PM, Thomas Gleixner wrote:
> > On Mon, 14 Jul 2014, Tejun Heo wrote:
> > 
> >> Hello,
> >>
> >> On Mon, Jul 14, 2014 at 04:13:21PM +0800, Lai Jiangshan wrote:
> >>> It is said in the document that the timer which is being
> >>> deleted by del_timer_sync() should not be restarted:
> >>>   Synchronization rules: Callers must prevent restarting of
> >>>   the timer, otherwise this function is meaningless.
> >>>
> >>> Repeating timer may cause the del_timer_sync() spin longer,
> >>> or even spin forever in very very very very extreme condition.
> >>
> >> I'm fairly sure del_timer_sync() can delete self-requeueing timers.
> >> The implementation busy-waits if the queued timer is the currently
> >> executing one and dequeues only while the timer isn't running which
> >> should be able to handle self-requeueing ones just fine.  Thomas,
> >> del_timer_sync() can reliably delete self-requeueing ones, right?
> > 
> > Yes. 
> 
> The comments of the del_timer_sync() needs to be updated
> if I did not misunderstood?
> 
> > If the timer callback is running on the other cpu, then it waits
> > for the callback to finish before checking whether the timer is
> > enqueued or not.
> 
> The syncer may be interrupted here, after it comes back, the timer
> may be running again (and maybe again and again).

No. The del_timer_sync() code holds the base lock with interrupts
disabled. So it can't be interrupted.

Thanks,

	tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ