On Fri, Mar 24, 2017 at 4:16 AM, Eric Dumazet [off-list ref] wrote:

On Thu, 2017-03-23 at 22:55 -0700, Alexander Duyck wrote:

quoted

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.