linux-kernel - Re: [PATCH 0/6] kselftest/arm64: Test floating point signal context restore 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f3f3807-a363-4847-a543-c97f2f405ce2@sirena.org.uk>
Date: Mon, 28 Oct 2024 15:38:07 +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 0/6] kselftest/arm64: Test floating point signal context
 restore in fp-stress

On Mon, Oct 28, 2024 at 02:26:44PM +0000, Mark Rutland wrote:

> 1) We only singal the tasks once a second. Dave's original shell test
>    script hammered this constantly, and it makes a substantial impact
>    actually triggering a bug.

>    Without these patches, I hacked the fp-stress.c main loop to trigger
>    a signal every ~1ms (by reducing the epoll_wait() timeout to 1 and
>    scaling the overall timeout to 10000 accordingly), and those changes
>    make the tests reliably trigger the "Bad SVCR" splats within a few
>    seconds after a few hundred signals, even if only using the SIGUSR2
>    tickle handlers.

>    Can we change the fp-stress.c main loop to signal threads more often?

Yeah, the once a second number was kind of pulled out of thin air (IIRC
I originally picked that for UI purposes and then added the signalling
later without specific purpose, I wasn't particularly referencing the
shell scripts here since I never used them much).  I don't see any
reason not to raise the rate, we do need it to be low enough to allow
the main loops of the test programs to make reasonable progress so
miliseconds feels like it might be a bit aggressive for a fully loaded
FVP configuration.  That'd be a separate patch anyway.

> 2) The SIGUSR2 tickle handlers are left behind. 

>    Given they're unused, it'd be nice to clean them up.

I don't see an urgent need to remove them, like the SIGUSR1 handlers
previously they're not doing any harm sitting there and could come in
handy when debugging things - the programs get a reasonable amount of
use standalone.

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