linux-kernel - Re: [PATCH 1/2] kselftest/arm64: Increase frequency of signal delivery in fp-stress

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <92fb0694-7a55-4e2f-9b59-8263a9dc58bc@sirena.org.uk>
Date: Tue, 29 Oct 2024 18:44:28 +0000
From: Mark Brown <broonie@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Shuah Khan <shuah@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] kselftest/arm64: Increase frequency of signal
 delivery in fp-stress

On Tue, Oct 29, 2024 at 03:43:37PM +0000, Mark Rutland wrote:

> On those emulated platforms (FVP?), does this change trigger the faukure
> more often?

Yes.

> I gave this a quick test, and with this change, running fp-stress on a
> defconfig kernel running on 1 CPU triggers the "Bad SVCR: 0" splat in
> 35/100 runs. Hacking that down to 5ms brings that to 89/100 runs. So
> even if we have to keep this high for an emulated platform, it'd
> probably be worth being able to override that as a parameter?

I was getting better numbers than that with the default multi-CPU setups
on my particular machine, most runs were showing something IIRC.  I do
agree that it'd be a useful command line argument to add incrementally.

> Otherwise, maybe it's worth increasing the timeout for the fp-stress
> test specifically? The docs at:

>   https://docs.kernel.org/dev-tools/kselftest.html#timeout-for-selftests

> ... imply that is possible, but don't say exactly how, and it seems
> legitimate for a stress test.

IIRC it's per suite and there's a bunch of pushback on using it in
default configurations since the selftests are expected to run quickly
in other cases where I'd have said it was a reasonable change to make.
Stress tests are not entirely idiomatic for kselftest, it's supposed to
run quickly.

> > +#define SIGNAL_INTERVAL_MS 25
> > +#define LOG_INTERVALS (1000 / SIGNAL_INTERVAL_MS)

> Running this, I see that by default test logs:

> 	# Will run for 400s

> ... for a timeout that's actually ~10s, due to the following, which isn't in
> the diff:

> 	if (timeout > 0)
> 		ksft_print_msg("Will run for %ds\n", timeout);

> ... so that probably wants an update to either convert to seconds or be in
> terms of signals, and likewise for the "timeout remaining" message below.

> Otherwise, this looks good to me.

Oh, yeah - we should probably just remove the unit from that one.  I
never see it due to all the spam from the subprocesses starting.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)