Re: [PATCH v10 clocksource 1/7] clocksource: Provide module parameters to inject delays in watchdog

[Andi Kleen]

> occur between the reads of the two clocks.  Yes, interrupts are disabled
> across those two reads, but there are no shortage of things that can
> delay interrupts-disabled regions of code ranging from SMI handlers to
> vCPU preemption.  It would be good to have some indication as to why

I assume vCPU preemption here refers to preempt RT? I didn't think
a standard kernel could preempt when interrupt are disabled.

>  
> +	clocksource.inject_delay_period= [KNL]
> +			Number of calls to clocksource_watchdog() before
> +			delays are injected between reads from the
> +			two clocksources.  Values of zero disable this
> +			delay injection.  These delays can cause clocks
> +			to be marked unstable, so use of this parameter
> +			should therefore be avoided on production systems.
> +			Defaults to zero (disabled).
> +
> +	clocksource.inject_delay_repeat= [KNL]
> +			Number of repeated clocksource_watchdog() delay
> +			injections per period.	If inject_delay_period
> +			is five and inject_delay_repeat is three, there
> +			will be five delay-free reads followed by three
> +			delayed reads.

I'm not sure command line options are the right way to do this.
How about integrating it with the fault injection framework in debugfs.

This way syzkaller etc. can play with it, which long term would
give much better test coverage.

This wouldn't allow boot time coverage, but presumably that's not
too important here.

-Andi