[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130529160150.f0a498d188dc790d018200e9@linux-foundation.org>
Date: Wed, 29 May 2013 16:01:50 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Bart Van Assche <bart.vanassche@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Arjan van de Ven <arjan@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-kernel <linux-kernel@...r.kernel.org>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] timer: Fix jiffies wrap behavior of round_jiffies*()
On Tue, 21 May 2013 20:43:50 +0200 Bart Van Assche <bart.vanassche@...il.com> wrote:
> Make sure that the round_jiffies*() functions return a time that is
> in the future when the jiffies counter is about to wrap.
Actually "when the jiffies counter has recently wrapped".
I assume this was found by inspection?
> @@ -149,9 +149,7 @@ static unsigned long round_jiffies_common(unsigned long j, int cpu,
> /* now that we have rounded, subtract the extra skew again */
> j -= cpu * 3;
> - if (j <= jiffies) /* rounding ate our timeout entirely; */
This used to be a very common bug - we've weeded out many instances but
I'm sure more still remain. We could perhaps have a checkpatch rule
which looks for comparisons against jiffes (and any other
time-measuring variables we can detect) and tells people to use
time_after() and friends, or time_is_*_jiffies().
> - return original;
> - return j;
> + return time_is_after_jiffies(j) ? j : original;
> }
Your email client mangles patches, btw.
--
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