[PATCH v2 0/4] selftests: arm64: vec-syscfg updates

Shuah Khan skhan at linuxfoundation.org
Wed Sep 29 09:26:49 PDT 2021


On 9/29/21 9:35 AM, Will Deacon wrote:
> On Wed, Sep 29, 2021 at 03:43:23PM +0100, Mark Brown wrote:
>> On Wed, Sep 29, 2021 at 03:31:14PM +0100, Will Deacon wrote:
>>
>>> With this series applied, I see a test failing under qemu with:
>>
>>> # selftests: arm64: vec-syscfg
>>> # TAP version 13
>>> # 1..10
>>> # ok 1 SVE default vector length 64
>>> # ok 2 # SKIP Need to be root to write to /proc
>>> # ok 3 # SKIP Need to be root to write to /proc
>>
>> AFAICT this is due to running as a non-root user, the testsuite was
>> already having serious issues before then...
>>
>>> # ok 4 SVE current VL is 64
>>> # ok 5 SVE set VL 64 and have VL 64
>>> # ok 6 # SKIP SVE only one VL supported
>>> # ok 7 # SKIP SVE only one VL supported
>>> # ok 8 # SKIP SVE only one VL supported
>>> # ok 9 # SKIP SVE only one VL supported
>>> # # SVE VL 272 returned 256 not maximum 0
>>
>> ...as it's starting off by testing an interface that's only writable by
>> root and then relying on that information, the existing tests were also
>> not working usefully.  qemu by default supports way more than one vector
>> length.  In any case it's just the test added by the last patch that's
>> causing the output here, the first four patches should be fine and fix
>> issues.
>>
>> I'm not sure it's a particularly good idea to run kselftest as a
>> non-root user TBH, it's going to cause you to skip a lot of tests.
> 

We don't want Kselftest default run to be as root. Users can choose to
run as root which would be an explicit choice so they expect and plan
for the impact. Example panic test.

> Ah, thanks for pointing that out. It would probably be better to skip the
> tests rather than fail them if they're not running with sufficient
> permissions, but I'll go ahead and queue your v3 for now.
> 

Correct. I would like to see tests skipped not failed if either config
or permissions are lacking to run the tests.

thanks,
-- Shuah



More information about the linux-arm-kernel mailing list