Hi -

On Wed, Nov 01, 2006 at 02:02:23PM -0800, Stone, Joshua I wrote:

> [...]  The easy-out answer is that stp_random_pm deals with ints,
> and I needed the randomization to be 64-bit.  [...]

Yeah, might as well upgrade the runtime's random_pm function.

> I also thought that using the kernel's get_random_bytes would yield
> better randomization [...]

The problem there is that this kernel facility uses locks of its own,
which would constitute another probing hazard area.


> On a related note, you broke the randomization on jiffies timers when
> used as ms.  [...]

Sorry about that.  I probably broke one or two other things by
mistake -- or out of spite! :-)


> [...]  But, this brings to mind a potential race in the startup,
> with both hrtimers and jiffies-timers.  In both cases, the timer
> only gets restarted if we run the probe, which only happens if the
> state is STAP_SESSION_RUNNING.  If a newly registered timer fires
> off while we're still initializing other code
> (STAP_SESSION_STARTING), the timer won't be restarted, and it will
> be useless for the whole session. [...]

Good catch.  How about this: rework enter_hrtimer_probe, so that the
timer expiration computation is done before the
common_probe_entryfn_prologue.  "But you can't have statements so
early!" I hear you cry.  Ahem!  Yes, you can - if it's nested within a
new block.  So:

  enter_hrtimer_probe (...) {
    timer->expires = [...];
    { /* <<<< */
       ... prologue etc.

       ... epilogue
    }
    return HRTIMER_RESTART;
 }

- FChE