[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21200.1510136616@warthog.procyon.org.uk>
Date: Wed, 08 Nov 2017 10:23:36 +0000
From: David Howells <dhowells@...hat.com>
To: tglx@...utronix.de
Cc: dhowells@...hat.com, torvalds@...ux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Is there a race between __mod_timer() and del_timer()?
David Howells <dhowells@...hat.com> wrote:
> I think it might just be best to put a note in the comments in __mod_timer().
How about the attached?
David
---
commit d538c734f9bf885292b88a81a06c5efee528d70d
Author: David Howells <dhowells@...hat.com>
Date: Wed Nov 8 10:20:27 2017 +0000
Add a comment into __mod_timer() noting a possible race with del_timer()
Add a comment into __mod_timer() noting a possible race with del_timer() in
which the 'common optimization' case could leave the timer unstarted if
del_timer() happens between the timer_pending() check and the timer
expiration check.
Signed-off-by: David Howells <dhowells@...hat.com>
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index f2674a056c26..e0ac4486529c 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -949,6 +949,9 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
* The downside of this optimization is that it can result in
* larger granularity than you would get from adding a new
* timer with this expiry.
+ *
+ * Note that if del_timer() happens whilst we're just here, we
+ * will return with the timer unstarted.
*/
if (timer->expires == expires)
return 1;
Powered by blists - more mailing lists