RE: offline elfutils processing committed

["Stone, Joshua I" <joshua dot i dot stone at intel dot com>]

On Wednesday, November 01, 2006 2:22 PM, Frank Ch. Eigler wrote:
> 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.

Upgrade?  Or create a new one as a 64-bit alternative?

>> 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.

I think it's ok in this case.  It helps that we know what context we're
calling from -- timers are run in soft-irqs.  The locks via
get_random_bytes use irqsave, so I don't think there's any way for us to
trap here.

>> 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! :-)

Yes, spite would be just like you... ;)

> 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;
>  }

Ok, and we'll need a similar thing for enter_timer_probe.  I'm worried
about this introducing races in shutdown though.  If we're trying to
remove the timers, then the timer body shouldn't restart itself.  I
suppose I could check for STAP_SESSION_STARTING/_RUNNING before
reloading the timer -- but we'll also need to change it so that when
init fails the cleanup takes us out of STARTING mode.


Josh