This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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
Attachment:
pgp00000.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |