The above is definitely wrong. You're changing "next" outside the timer
lock, which means that suddenly the consistency of next is not guaranteed
(imagine another CPU waiting on the lock to do an "add_timer()" on that
timer when you exit from the above - now you're going to have a race where
both CPU's potentially change the entries at the same time.
Bad idea.
> - expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
> + expire = (long) (timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec));
> + /*
> + * Handle a too high timeout for the scheduler after the
> + * struct timespec to jiffies conversion. -arca
> + */
> + if (expire < 0)
> + expire = MAX_SCHEDULE_TIMEOUT;
Naah, much better to just say that "max-jiffies" as returned from the
timespec_to_jiffies() routine must allow people to add one for rounding
purposes. That just changes a test against MAX_LONG to (MAX_LONG-1)
instead of introducing strange things like the above.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/