Re: [PATCH v2] selftests/x86: add "ffff8" -- kernel memory scanner

[Dave Hansen <dave.hansen@intel.com>]

On 10/31/22 23:45, Alexey Dobriyan wrote:
> On Mon, Oct 31, 2022 at 02:37:43PM -0700, Dave Hansen wrote:
>> On 10/29/22 10:25, Alexey Dobriyan wrote:
>>> 	$ ./ffff8_64 -h
>>> 	usage: ./ffff8_64 [-f] [-r] [-n N] [-s S]
>>> 	        -f: sequential scan
>>> 	        -r: random scan (default)
>>> 	        -n: use N threads (default: $(nproc))
>>> 	        -s: lowest address shift (default: 47)
>>> 	        -t: time to run (default: 256 seconds)
>> Does this mean that if someone is just running all kernel selftests,
>> they need to wait for 256 seconds for this to finish?
> Yes. But low time will cover negligible amount of address space.
> 
> Is there some kind of policy to not do this? LTP surely has similar
> tests for races.

There's no written policy that I know of.  But, right now, the entirety
of the x86 selftests will run in a second or two.  It's actually
something I run in a loop to stress the entry/exit paths when I'm
messing with them.  Something silly like this:

	for i in *_32 *_64; do ./$i; done

Just picking a number out of thin air, I'd say that running for a couple
of seconds, like 2 is fine by default for any one tests.  Longer than
that, and it'll be out of whack with all the other x86 selftests.  If
it's 256 seconds, it just won't get run.

Yes, a single run will not have as much coverage, but a lot of people
run those tests (think 0day) and some folks run them a *lot*, like how I
run them in a loop.

The MPX selftest that was in there was in a similar situation.  It
*could* run for a long, long time and that helped because address
randomization would eventually help find some of the nastier corner
cases.  But, it was limited to a few seconds.

I really think we should stick to just a few seconds at most for any
individual test.