[Potential Regression] tm-resched-dscr from powerpc in ubuntu_kernel_selftests failed on B/E/F

[Po-Hsu Lin]

Issue found on 5.3.0-64.58 with P8 node modoc (skipped with P9 node)

# selftests: powerpc/tm: tm-resched-dscr
# test: tm_resched_dscr
# tags: git_version:unknown
# Binding to cpu 8
# main test running as pid 142637
# Check DSCR TM context switch: FAIL
# failure: tm_resched_dscr
not ok 1 selftests: powerpc/tm: tm-resched-dscr # exit=1

[Po-Hsu Lin (cypressyew)]

Test passed with 5.3.0-62.56:
# selftests: powerpc/tm: tm-resched-dscr
# test: tm_resched_dscr
# tags: git_version:f21e446-dirty
# Binding to cpu 8
# main test running as pid 144067
# Check DSCR TM context switch: OK
# success: tm_resched_dscr
ok 1 selftests: powerpc/tm: tm-resched-dscr

[Po-Hsu Lin (cypressyew)]

I can see this failure in 5.3.0-63.57-generic as well.

[Po-Hsu Lin (cypressyew)]

Since this 5.3.0-64.58 is a respin for 5.3.0-63.57, I think we can call this a potential regression.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1888334

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Po-Hsu Lin (cypressyew)]

I can reproduce this on 5.3.0-64.58 with the testing tools in 5.3.0-62.56 kernel tree.

[Po-Hsu Lin (cypressyew)]

This failure can be found in ADT as well, but the test result was marked as GOOD
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/ppc64el/l/linux/20200716_044014_6bbbe@/log.gz

[Po-Hsu Lin (cypressyew)]

Affecting Focal P8 as well

Note that you will have to review it directly on jenkins, the whole test suite terminates at the ftracetest

[Po-Hsu Lin (cypressyew)]

This failure can be found on .15.0-114.115 / 4.15.0-114.115~16.04.1 PowerPC as well

[Po-Hsu Lin (cypressyew)]

On Bionic P8, I can reproduce this issue against proposed kernel (4.15.0-114.115) with source code in 4.15.0-112. Indicating this might be a kernel issue instead of a test case issue.

[Po-Hsu Lin (cypressyew)]

Note for Bionic P9, this test was skipped on node baltar.

[Po-Hsu Lin (cypressyew)]

A bisect for arch/powerpc/ shows this is the first bad commit:

$ git bisect bad
7d10952e8a56f87a53fc57594078555a9dfd4a07 is the first bad commit
commit 7d10952e8a56f87a53fc57594078555a9dfd4a07
Author: Michael Ellerman <email address hidden>
Date: Thu May 28 00:58:42 2020 +1000

    powerpc/64s: Save FSCR to init_task.thread.fscr after feature init

    BugLink: https://bugs.launchpad.net/bugs/1885176

    commit 912c0a7f2b5daa3cbb2bc10f303981e493de73bd upstream.

    At boot the FSCR is initialised via one of two paths. On most systems
    it's set to a hard coded value in __init_FSCR().

    On newer skiboot systems we use the device tree CPU features binding,
    where firmware can tell Linux what bits to set in FSCR (and HFSCR).

    In both cases the value that's configured at boot is not propagated
    into the init_task.thread.fscr value prior to the initial fork of init
    (pid 1), which means the value is not used by any processes other than
    swapper (the idle task).

    For the __init_FSCR() case this is OK, because the value in
    init_task.thread.fscr is initialised to something sensible. However it
    does mean that the value set in __init_FSCR() is not used other than
    for swapper, which is odd and confusing.

    The bigger problem is for the device tree CPU features case it
    prevents firmware from setting (or clearing) FSCR bits for use by user
    space. This means all existing kernels can not have features
    enabled/disabled by firmware if those features require
    setting/clearing FSCR bits.

    We can handle both cases by saving the FSCR value into
    init_task.thread.fscr after we have initialised it at boot. This fixes
    the bug for device tree CPU features, and will allow us to simplify
    the initialisation for the __init_FSCR() case in a future patch.

    Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
    Cc: <email address hidden> # v4.12+
    Signed-off-by: Michael Ellerman <email address hidden>
    Link: https://<email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Signed-off-by: Kamal Mostafa <email address hidden>
    Signed-off-by: Khalid Elmously <email address hidden>

    :040000 040000 9c654d310ed9b7c4a1cf16620d120ec93624eda3
    05b34a61190e63ccde3b7d02e2183dc64b32c812 M arch

$ git bisect log
git bisect start '--' 'arch/powerpc/'
\# bad: [f4daf25f7f8608d1c14c85ea0b73c9e1e1eb2dba] UBUNTU: Ubuntu-4.15.0-114.115
git bisect bad f4daf25f7f8608d1c14c85ea0b73c9e1e1eb2dba
\# good: [495149ddc61a5997857fda041ccd4c81cac46e00] UBUNTU: Ubuntu-4.15.0-112.113
git bisect good 495149ddc61a5997857fda041ccd4c81cac46e00
\# bad: [07ad1246146fa49430d2455bd45db1c8da4d521c] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
git bisect bad 07ad1246146fa49430d2455bd45db1c8da4d521c
\# good: [f30471f4138df69bd4585d91c1f31a282daa41e7] powerpc/64s: Don't let DT CPU features set FSCR_DSCR
git bisect good f30471f4138df69bd4585d91c1f31a282daa41e7
\# bad: [0e198dfae237e9a9654d87b7c6df12146feaec26] sched/core: ...

[Thadeu Lima de Souza Cascardo (cascardo)]

Same thing as LP: #1888332. When writing to the privileged DSCR MSR before running the remainder of the test, things will just work. This is hinting again to dscr_inherit being unset when using the user DSCR MSR.

Cascardo.