sys_fuzz

[Hal Murray]

esr at thyrsus.com said:
> Sure.  But if my new understanding is correct, all *this* problem requires
> is stepback protection, not fuzzing.  Please check me on that.  Worst case,
> lots of migration could make the TSC look a bit like a random variable with
> a very low frequency of collisions (proportional to (2^64)^-2 by birthday
> effect); filtered through the stepback check this would look a lot like
> fuzzing. 

Why are collisions interesting?

I think your math is way off.  It would be right for 64 bit random samples, 
but TSC values are not random.  If you boot two identical machines an hour 
apart, a sample from one machine will never match a sample from the other 
machine if the samples are collected at roughly the same time.  (Adjust "an 
hour" and "roughly" as needed.)

If the machines are similar (aka same brand and specs and such) then the TSC 
counters will tick at slightly different rates.  Half the time they will 
drift apart.  The other half, they will get closer until they cross, then 
drift apart.  If you sample when they are close you might get a match.  
Otherwise, see above.


> It occurs to me that one reason to jump is that in the SMP case we have no
> guarantee that the fuzz calculation itself is reliable. I mean, what happens
> if a process migration intervenes between the "adjacent" measurement calls? 

We are assuming that the kernel generates correct time.

You could add writing code to check for that to your list.  Feels like shared 
memory and a thread per CPU, but I don't have any good ideas for the inner 
loop.


-- 
These are my opinions.  I hate spam.