On Thu, 2017-03-23 at 22:55 -0700, Alexander Duyck wrote: > Right, but time_after assumes roll over. When you are using a time > value based off of local_clock() >> 10, you don't ever roll over when > you do addition. Just the clock rolls over. At least on 64 bit > systems. > > So if local time approaches something like all 1's, and we have > shifted it by 10 it is then the max it can ever reach is > 0x003FFFFFFFFFFFFF. I can add our loop time to that and it won't roll > over. In the mean time the busy_loop_us_ can never exceed whatever I > added to that so we are now locked into a loop. I realize I am > probably being pedantic, and it will have an exceedingly small rate of > occurrence, but it is still an issue. Do you realize that a 64bit clock wont rollover before the host has reached 584 years of uptime ? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
