On Fri, Mar 24, 2017 at 4:16 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > 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 ? Yeah, that is what I meant by "probably being pedantic". I was being a too much of a perfectionist. So I can work with the ">> 10" approach. The only thing I think I may still want to change is that on 32b systems I will still use the do_procintvec_minmax for busy_poll and busy_read to prevent us from inputting values less than 0. For 64b systems we can do_procuintvec. It isn't so much that I don't trust root, it is just that we didn't really document the ranges anywhere for this so I figure if we at least lock that down to the usable ranges since root may not be aware of the implementation details. -- 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
