Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 26 Apr 2021 08:28:01 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Andi Kleen <ak@linux.intel.com>
Cc:     tglx@linutronix.de, linux-kernel@vger.kernel.org,
        john.stultz@linaro.org, sboyd@kernel.org, corbet@lwn.net,
        Mark.Rutland@arm.com, maz@kernel.org, kernel-team@fb.com,
        neeraju@codeaurora.org, feng.tang@intel.com,
        zhengjun.xing@intel.com, Chris Mason <clm@fb.com>
Subject: Re: [PATCH v10 clocksource 1/7] clocksource: Provide module
 parameters to inject delays in watchdog
Message-ID: <20210426152801.GY975577@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20210425224540.GA1312438@paulmck-ThinkPad-P17-Gen-1>
 <20210425224709.1312655-1-paulmck@kernel.org>
 <20210426040736.GS1401198@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210426040736.GS1401198@tassilo.jf.intel.com>
Precedence: bulk

On Sun, Apr 25, 2021 at 09:07:36PM -0700, Andi Kleen wrote:

[ . . . ]

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

Boot-time coverage is important, as we saw in kbuild test robot testing
of v9 of this patchset, which triggered clocksource_tsc_early, but not
clocksource_tsc.  Note that v10 avoids this triggering.

							Thanx, Paul