I just found the following change in the ncr53c8xx driver:
+ if (lp && time_before_eq(lp->tags_stime + 3*HZ, jiffies)) {
- if (lp && lp->tags_stime + (3*HZ) <= jiffies) {
I do prefer a known bug that such a _not_ needed ambiguous construct, for
the reason that, each time the arguments of time_before_eq() are
_unfortunately_ in the reverse order we just get the opposite effect.
Running such a risk for the hundreds of comparisons against jiffies that
happen in the kernel is moronic in all the places not only in the first
one.
Writing programs this way, that multiplies bug probability by an order of
magnitude when it is _not_ needed, is way stupid, in my opinion.
The constructs I would have accepted looks like the following, for
example:
Either,
+ if (lp && time_before_jiffies_eq(lp->tags_stime + 3*HZ)) {
Or,
+ if (lp && not_in_the_future(lp->tags_stime + 3*HZ)) {
(And define appropriate macros if needed)
Regards,
Gérard.
-
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/