[Xenomai] [PATCH] testsuite/switchtest/x86: allow in kernel-FPU testing

Philippe Gerum rpm at xenomai.org
Thu Feb 2 10:43:33 CET 2017

On 01/27/2017 03:36 PM, Henning Schild wrote:
> On Fri, 27 Jan 2017 15:10:59 +0100
> Philippe Gerum <rpm at xenomai.org> wrote:
>> On 01/27/2017 03:04 PM, Henning Schild wrote:
>>> On Fri, 27 Jan 2017 14:52:22 +0100
>>> Henning Schild <henning.schild at siemens.com> wrote:
>>>> Not running the in-kernel FPU tests while Linux might be using the
>>>> FPU in kernel-mode is a safeguard measure for development versions
>>>> that might still have issues with FPU context switching. i.e. it
>>>> prevents data corruption on RAIDs beeing triggered by an FPU Bug.
>>>> In a bug-free kernel running the switchtest in kernel-mode is not a
>>>> problem and may be desired for proper test-coverage.
>>>> This patch introduces a command line option to switchtest to allow
>>>> overriding the safeguard.  
>>> I am not sure i am happy with this solution either. Actually the
>>> test should always run as part of the unit tests. It is very
>>> valuable and skipping it "silently" is a really bad idea.
>>> If it is really just disabled for when it might mess with your raid
>>> on the machine you do kernel development on, maybe you should not
>>> use such a machine for that?
>>> So i am starting to think the test should run by default and the
>>> conservative version should be opt-in instead of opt-out.
>> A conservative version can only be opt-out, otherwise people may run
>> into damages without knowing, which would defeat the intent of picking
>> the conservative approach.
> There should at least be a prominent notice that an important test was
> skipped. The once-printk is just not the right place. Maybe the whole
> testcase should fail instead so that people have to say
> --kfpu-may-be-skipped

That sounds like a fair compromise.

> Maybe i still did not fully understand why the test gets skipped. I
> have seen CONFIG_CIFS_SMB2 trigger the FPU problem in the broken 4.1.
> Would that be a reason to add that to the list of switches skipping the
> test? Or is the whole thing really just there to protect devs from
> messing up their raids?

I seem to remember that Gilles and I eventually agreed a long time ago
on skipping those tests, due to the impossibility for us to reach a
proper test coverage for fpu in kernel space when those options are
enabled, with potentially hard damages upon bugs (e.g. RAID). Given that
fpu support in kernel space over real-time threads was already
deprecated at that time, we did not see any point in making the test and
maintenance process even more complex to keep it as a first class citizen.

> I do not see who does kernel development on a machine so valueable to
> justify skipping such an important test for everyone.

Well, I must admit that I would not run a development version of any
kernel code on a system which holds critically important data either.
But I don't think that we can impose such a restriction on people
competing for the Darwin Awards.

>> I'm still pondering whether this test makes sense in 3.x, given that
>> official support for running fpu ops over rt threads in kernel space
>> was dropped for that version. Too much of a mess.
> Ok, i am actually again looking primarily at xenomai-2 and was planning
> on backporting whatever we come up with.

I'm ok with pushing this to the 2.x branch, but then I'll cowardly let
you deal with any follow up from the user base regarding this.


More information about the Xenomai mailing list