Messages in this thread | | | Date | Wed, 12 Sep 2007 01:50:57 +0200 | From | Björn Steinbrink <> | Subject | Re: time_after - what on earth??? |
| |
On 2007.09.12 00:10:19 +0100, Adrian McMenamin wrote: > On 12/09/2007, Björn Steinbrink <B.Steinbrink@gmx.de> wrote: > > On 2007.09.12 00:19:09 +0200, Rene Herman wrote: > > > On 09/12/2007 12:15 AM, Adrian McMenamin wrote: > > > > > >> On 11/09/2007, Rene Herman <rene.herman@gmail.com> wrote: > > >>> On 09/12/2007 12:05 AM, Adrian McMenamin wrote: > > >>> > > >>>> OK, why does this line occasionally return true: > > > > What exactly is "occassionally"? Does it happen more than once per > > boot? If not, and it happens after a certain time after booting, it > > might be wrapping of the jiffie counter (see below). > > > > >>>> > > >>>> if ((maple_dev->interval > 0) && (jiffies >maple_dev->when)) > > >>>> > > >>>> while this one never does (no other changes made): > > >>>> > > >>>> if ((maple_dev->interval > 0) && (time_after(jiffies, > > >>>> maple_dev->when))) > > >>> Is maple_dev->when an unsigned long? > > >>> > > >> Yes. Does that make a difference? > > > > > > If it had been a signed type, it could've wrapped to something you didn't > > > expect, explaining the difference at least... > > > > > > With an unsigned long, the only diference should be that time_after() deals > > > with jiffie wrapping which I assume is not an actual problem here. I'll > > > retreat into the shades again... ;-( > > > > If "occasionally" is limited to once per boot, it might be jiffie > > wrapping. IIRC jiffies are initialized so that they wrap after about 5 > > minutes of uptime to reveal such bugs without forcing you to wait for > > ages just to have the counter wrap for the first time. > > > > No, I mean "works properly" - ie occasionally evaluates as true
Ehrm, yeah, I somehow parsed that as if it had a negation in there.
Anyway, I looked up the patches you posted. "when" is initialized to 0 and only changed if the above condition evaluates to true. Now, time_after and "<" have different points at which "future" and "past" are separated. time_after splits (about) equally between future and past, so 0 can be either, depending on the value of jiffies. But for "<" 0 is almost always in the past, except for the seldom event of jiffies being 0.
Now, given that jiffies start out at a huge value to make the counter wrap around early, 0 happens to be in the "future" for time_after, until the wrap around occurs. So in your case, you just might have to wait those 5 minutes to get the working behaviour, instead of the common case in which it breaks after that time ;-)
A fix would likely initialize "when" to jiffies.
Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |