This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.9.316-rc1
Yang Yingliang yangyingliang@huawei.com net: stmmac: fix missing pci_disable_device() on error in stmmac_pci_probe()
Yang Yingliang yangyingliang@huawei.com ethernet: tulip: fix missing pci_disable_device() on error in tulip_init_one()
Felix Fietkau nbd@nbd.name mac80211: fix rx reordering with non explicit / psmp ack policy
Gleb Chesnokov Chesnokov.G@raidix.com scsi: qla2xxx: Fix missed DMA unmap for aborted commands
Thomas Richter tmricht@linux.ibm.com perf bench numa: Address compiler error on s390
Kevin Mitchell kevmitch@arista.com igb: skip phy status check where unavailable
Ard Biesheuvel ardb@kernel.org ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2
Ard Biesheuvel ardb@kernel.org ARM: 9196/1: spectre-bhb: enable for Cortex-A15
Jiasheng Jiang jiasheng@iscas.ac.cn net: af_key: add check for pfkey_broadcast in function pfkey_process
Duoming Zhou duoming@zju.edu.cn NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
Christophe JAILLET christophe.jaillet@wanadoo.fr net/qla3xxx: Fix a test in ql_reset_work()
Zixuan Fu r33s3n6@gmail.com net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()
Zixuan Fu r33s3n6@gmail.com net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf()
Hangyu Hua hbh25y@gmail.com drm/dp/mst: fix a possible memory leak in fetch_monitor_name()
Peter Zijlstra peterz@infradead.org perf: Fix sys_perf_event_open() race against self
Takashi Iwai tiwai@suse.de ALSA: wavefront: Proper check of get_user() error
Ulf Hansson ulf.hansson@linaro.org mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()
Ulf Hansson ulf.hansson@linaro.org mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD
Ulf Hansson ulf.hansson@linaro.org mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC
linyujun linyujun809@huawei.com ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()
Jakob Koschel jakobkoschel@gmail.com drbd: remove usage of list iterator variable after loop
Xiaoke Wang xkernel.wang@foxmail.com MIPS: lantiq: check the return value of kzalloc()
Jeff LaBundy jeff@labundy.com Input: add bounds checking to input_set_capability()
David Gow davidgow@google.com um: Cleanup syscall_handler_t definition/cast, fix warning
Willy Tarreau w@1wt.eu floppy: use a statically allocated error counter
-------------
Diffstat:
Makefile | 4 +-- arch/arm/kernel/entry-armv.S | 2 +- arch/arm/kernel/stacktrace.c | 10 +++--- arch/arm/mm/proc-v7-bugs.c | 1 + arch/mips/lantiq/falcon/sysctrl.c | 2 ++ arch/mips/lantiq/xway/gptu.c | 2 ++ arch/mips/lantiq/xway/sysctrl.c | 46 +++++++++++++++--------- arch/x86/um/shared/sysdep/syscalls_64.h | 5 ++- drivers/block/drbd/drbd_main.c | 7 ++-- drivers/block/floppy.c | 19 +++++----- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/input/input.c | 19 ++++++++++ drivers/mmc/card/block.c | 6 ++-- drivers/mmc/core/core.c | 5 ++- drivers/mmc/core/mmc_ops.c | 9 ++--- drivers/net/ethernet/dec/tulip/tulip_core.c | 5 ++- drivers/net/ethernet/intel/igb/igb_main.c | 3 +- drivers/net/ethernet/qlogic/qla3xxx.c | 3 +- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +-- drivers/net/vmxnet3/vmxnet3_drv.c | 6 ++++ drivers/scsi/qla2xxx/qla_target.c | 3 ++ kernel/events/core.c | 14 ++++++++ net/key/af_key.c | 6 ++-- net/mac80211/rx.c | 3 +- net/nfc/nci/data.c | 2 +- net/nfc/nci/hci.c | 4 +-- sound/isa/wavefront/wavefront_synth.c | 3 +- tools/perf/bench/numa.c | 2 +- 28 files changed, 134 insertions(+), 62 deletions(-)
On 5/23/22 10:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli f.fainelli@gmail.com
On 5/23/22 11:03 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah
Hi Greg,
On 23/05/2022 18:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
...
Ard Biesheuvel ardb@kernel.org ARM: 9196/1: spectre-bhb: enable for Cortex-A15
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Thanks Jon
On Tue, May 24, 2022 at 09:32:07AM +0100, Jon Hunter wrote:
Hi Greg,
On 23/05/2022 18:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Pseudo-Shortlog of commits:
...
Ard Biesheuvel ardb@kernel.org ARM: 9196/1: spectre-bhb: enable for Cortex-A15
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Odd. This is also in 5.10.y, right? No issues there? Are we missing something?
On 24/05/2022 13:09, Greg Kroah-Hartman wrote:
...
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Odd. This is also in 5.10.y, right? No issues there? Are we missing something?
Actually, the more I look at this, the more I see various intermittent reports with this and it is also impacting the mainline.
The problem is that the commit in question is causing a ton of messages to be printed a boot and this sometimes is causing the boot test to fail because the boot is taking too long. The console shows ...
[ 1233.327547] CPU0: Spectre BHB: using loop workaround [ 1233.327795] CPU1: Spectre BHB: using loop workaround [ 1233.328270] CPU1: Spectre BHB: using loop workaround [ 1233.328700] CPU1: Spectre BHB: using loop workaround [ 1233.355477] CPU2: Spectre BHB: using loop workaround ** 7 printk messages dropped ** [ 1233.366271] CPU0: Spectre BHB: using loop workaround [ 1233.366580] CPU0: Spectre BHB: using loop workaround [ 1233.366815] CPU1: Spectre BHB: using loop workaround [ 1233.405475] CPU1: Spectre BHB: using loop workaround [ 1233.405874] CPU0: Spectre BHB: using loop workaround [ 1233.406041] CPU1: Spectre BHB: using loop workaround ** 1 printk messages dropped **
There is a similar report of this [0] and I believe that we need a similar fix for the above prints as well. I have reported this to Ard [1]. So I am not sure that these Spectre BHB patches are quite ready for stable.
Cheers Jon
[0] https://lore.kernel.org/linux-arm-kernel/20220519161310.1489625-1-dmitry.osi... [1] https://lore.kernel.org/linux-arm-kernel/a589f56d-a0e1-328d-e4be-9427342d46b...
On Tue, May 24, 2022 at 03:55:58PM +0100, Jon Hunter wrote:
On 24/05/2022 13:09, Greg Kroah-Hartman wrote:
...
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Odd. This is also in 5.10.y, right? No issues there? Are we missing something?
Actually, the more I look at this, the more I see various intermittent reports with this and it is also impacting the mainline.
The problem is that the commit in question is causing a ton of messages to be printed a boot and this sometimes is causing the boot test to fail because the boot is taking too long. The console shows ...
[ 1233.327547] CPU0: Spectre BHB: using loop workaround [ 1233.327795] CPU1: Spectre BHB: using loop workaround [ 1233.328270] CPU1: Spectre BHB: using loop workaround [ 1233.328700] CPU1: Spectre BHB: using loop workaround [ 1233.355477] CPU2: Spectre BHB: using loop workaround ** 7 printk messages dropped ** [ 1233.366271] CPU0: Spectre BHB: using loop workaround [ 1233.366580] CPU0: Spectre BHB: using loop workaround [ 1233.366815] CPU1: Spectre BHB: using loop workaround [ 1233.405475] CPU1: Spectre BHB: using loop workaround [ 1233.405874] CPU0: Spectre BHB: using loop workaround [ 1233.406041] CPU1: Spectre BHB: using loop workaround ** 1 printk messages dropped **
There is a similar report of this [0] and I believe that we need a similar fix for the above prints as well. I have reported this to Ard [1]. So I am not sure that these Spectre BHB patches are quite ready for stable.
These patches are quite small, and just enable it for this known-broken cpu type.
If there is an issue enabling it for this cpu type, then we can work on that upstream, but there shouldn't be a reason to prevent this from being merged now, especially given that it is supposed to be fixing a known issue.
thanks,
greg k-h
On 5/24/22 08:06, Greg Kroah-Hartman wrote:
On Tue, May 24, 2022 at 03:55:58PM +0100, Jon Hunter wrote:
On 24/05/2022 13:09, Greg Kroah-Hartman wrote:
...
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Odd. This is also in 5.10.y, right? No issues there? Are we missing something?
Actually, the more I look at this, the more I see various intermittent reports with this and it is also impacting the mainline.
The problem is that the commit in question is causing a ton of messages to be printed a boot and this sometimes is causing the boot test to fail because the boot is taking too long. The console shows ...
[ 1233.327547] CPU0: Spectre BHB: using loop workaround [ 1233.327795] CPU1: Spectre BHB: using loop workaround [ 1233.328270] CPU1: Spectre BHB: using loop workaround [ 1233.328700] CPU1: Spectre BHB: using loop workaround [ 1233.355477] CPU2: Spectre BHB: using loop workaround ** 7 printk messages dropped ** [ 1233.366271] CPU0: Spectre BHB: using loop workaround [ 1233.366580] CPU0: Spectre BHB: using loop workaround [ 1233.366815] CPU1: Spectre BHB: using loop workaround [ 1233.405475] CPU1: Spectre BHB: using loop workaround [ 1233.405874] CPU0: Spectre BHB: using loop workaround [ 1233.406041] CPU1: Spectre BHB: using loop workaround ** 1 printk messages dropped **
There is a similar report of this [0] and I believe that we need a similar fix for the above prints as well. I have reported this to Ard [1]. So I am not sure that these Spectre BHB patches are quite ready for stable.
These patches are quite small, and just enable it for this known-broken cpu type.
If there is an issue enabling it for this cpu type, then we can work on that upstream, but there shouldn't be a reason to prevent this from being merged now, especially given that it is supposed to be fixing a known issue.
Jonathan any chance this is Tegra specific? Our ARCH_BRCMSTB SoCs which use a Brahma-B15 which uses nearly the same ca15 processor functions defined in arch/arm/mm/proc-v7.S reports the following *before* changes:
[ 0.001641] CPU: Testing write buffer coherency: ok [ 0.001685] CPU0: Spectre v2: using ICIALLU workaround [ 0.001703] ftrace: allocating 30541 entries in 120 pages [ 0.044600] CPU0: update cpu_capacity 1024 [ 0.044633] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.044662] Setting up static identity map for 0x200000 - 0x200060 [ 0.047410] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048974] CPU1: update cpu_capacity 1024 [ 0.048978] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048981] CPU1: Spectre v2: using ICIALLU workaround [ 0.050234] CPU2: update cpu_capacity 1024 [ 0.050238] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.050241] CPU2: Spectre v2: using ICIALLU workaround [ 0.051437] CPU3: update cpu_capacity 1024 [ 0.051441] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.051444] CPU3: Spectre v2: using ICIALLU workaround [ 0.051532] Brought up 4 CPUs
and this *after* merging 4.9.316-rc1:
[ 0.001626] CPU: Testing write buffer coherency: ok [ 0.001670] CPU0: Spectre v2: using ICIALLU workaround [ 0.001689] CPU0: Spectre BHB: using loop workaround [ 0.001705] ftrace: allocating 30542 entries in 120 pages [ 0.043752] CPU0: update cpu_capacity 1024 [ 0.043784] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.043813] Setting up static identity map for 0x200000 - 0x200060 [ 0.046547] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048121] CPU1: update cpu_capacity 1024 [ 0.048124] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048129] CPU1: Spectre v2: using ICIALLU workaround [ 0.048165] CPU1: Spectre BHB: using loop workaround [ 0.049398] CPU2: update cpu_capacity 1024 [ 0.049402] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.049405] CPU2: Spectre v2: using ICIALLU workaround [ 0.049440] CPU2: Spectre BHB: using loop workaround [ 0.050613] CPU3: update cpu_capacity 1024 [ 0.050617] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.050619] CPU3: Spectre v2: using ICIALLU workaround [ 0.050653] CPU3: Spectre BHB: using loop workaround [ 0.050722] Brought up 4 CPUs [ 0.050738] SMP: Total of 4 processors activated (216.00 BogoMIPS). [ 0.050753] CPU: All CPU(s) started in HYP mode.
On 24/05/2022 17:30, Florian Fainelli wrote:
...
Jonathan any chance this is Tegra specific? Our ARCH_BRCMSTB SoCs which use a Brahma-B15 which uses nearly the same ca15 processor functions defined in arch/arm/mm/proc-v7.S reports the following *before* changes:
[ 0.001641] CPU: Testing write buffer coherency: ok [ 0.001685] CPU0: Spectre v2: using ICIALLU workaround [ 0.001703] ftrace: allocating 30541 entries in 120 pages [ 0.044600] CPU0: update cpu_capacity 1024 [ 0.044633] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.044662] Setting up static identity map for 0x200000 - 0x200060 [ 0.047410] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048974] CPU1: update cpu_capacity 1024 [ 0.048978] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048981] CPU1: Spectre v2: using ICIALLU workaround [ 0.050234] CPU2: update cpu_capacity 1024 [ 0.050238] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.050241] CPU2: Spectre v2: using ICIALLU workaround [ 0.051437] CPU3: update cpu_capacity 1024 [ 0.051441] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.051444] CPU3: Spectre v2: using ICIALLU workaround [ 0.051532] Brought up 4 CPUs
and this *after* merging 4.9.316-rc1:
[ 0.001626] CPU: Testing write buffer coherency: ok [ 0.001670] CPU0: Spectre v2: using ICIALLU workaround [ 0.001689] CPU0: Spectre BHB: using loop workaround [ 0.001705] ftrace: allocating 30542 entries in 120 pages [ 0.043752] CPU0: update cpu_capacity 1024 [ 0.043784] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.043813] Setting up static identity map for 0x200000 - 0x200060 [ 0.046547] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048121] CPU1: update cpu_capacity 1024 [ 0.048124] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048129] CPU1: Spectre v2: using ICIALLU workaround [ 0.048165] CPU1: Spectre BHB: using loop workaround [ 0.049398] CPU2: update cpu_capacity 1024 [ 0.049402] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.049405] CPU2: Spectre v2: using ICIALLU workaround [ 0.049440] CPU2: Spectre BHB: using loop workaround [ 0.050613] CPU3: update cpu_capacity 1024 [ 0.050617] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.050619] CPU3: Spectre v2: using ICIALLU workaround [ 0.050653] CPU3: Spectre BHB: using loop workaround [ 0.050722] Brought up 4 CPUs [ 0.050738] SMP: Total of 4 processors activated (216.00 BogoMIPS). [ 0.050753] CPU: All CPU(s) started in HYP mode.
Does your platform support CPU idle? I see this being triggered during CPU idle transitions ...
[ 4.415167] CPU0: Spectre BHB: using loop workaround [ 4.417621] [<c01109a0>] (unwind_backtrace) from [<c010b7ac>] (show_stack+0x10/0x14) [ 4.430291] [<c010b7ac>] (show_stack) from [<c09c2b38>] (dump_stack+0xc0/0xd4) [ 4.437512] [<c09c2b38>] (dump_stack) from [<c011a6c8>] (cpu_v7_spectre_bhb_init+0xd8/0x190) [ 4.445943] [<c011a6c8>] (cpu_v7_spectre_bhb_init) from [<c010dee8>] (cpu_suspend+0xac/0xc8) [ 4.454377] [<c010dee8>] (cpu_suspend) from [<c011e7e4>] (tegra114_idle_power_down+0x74/0x78) [ 4.462898] [<c011e7e4>] (tegra114_idle_power_down) from [<c06d3b44>] (cpuidle_enter_state+0x130/0x524) [ 4.472286] [<c06d3b44>] (cpuidle_enter_state) from [<c0164a30>] (do_idle+0x1b0/0x200) [ 4.480199] [<c0164a30>] (do_idle) from [<c0164d28>] (cpu_startup_entry+0x18/0x1c) [ 4.487762] [<c0164d28>] (cpu_startup_entry) from [<801018cc>] (0x801018cc)
Jon
On 5/24/22 10:50, Jon Hunter wrote:
On 24/05/2022 17:30, Florian Fainelli wrote:
...
Jonathan any chance this is Tegra specific? Our ARCH_BRCMSTB SoCs which use a Brahma-B15 which uses nearly the same ca15 processor functions defined in arch/arm/mm/proc-v7.S reports the following *before* changes:
[ 0.001641] CPU: Testing write buffer coherency: ok [ 0.001685] CPU0: Spectre v2: using ICIALLU workaround [ 0.001703] ftrace: allocating 30541 entries in 120 pages [ 0.044600] CPU0: update cpu_capacity 1024 [ 0.044633] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.044662] Setting up static identity map for 0x200000 - 0x200060 [ 0.047410] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048974] CPU1: update cpu_capacity 1024 [ 0.048978] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048981] CPU1: Spectre v2: using ICIALLU workaround [ 0.050234] CPU2: update cpu_capacity 1024 [ 0.050238] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.050241] CPU2: Spectre v2: using ICIALLU workaround [ 0.051437] CPU3: update cpu_capacity 1024 [ 0.051441] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.051444] CPU3: Spectre v2: using ICIALLU workaround [ 0.051532] Brought up 4 CPUs
and this *after* merging 4.9.316-rc1:
[ 0.001626] CPU: Testing write buffer coherency: ok [ 0.001670] CPU0: Spectre v2: using ICIALLU workaround [ 0.001689] CPU0: Spectre BHB: using loop workaround [ 0.001705] ftrace: allocating 30542 entries in 120 pages [ 0.043752] CPU0: update cpu_capacity 1024 [ 0.043784] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.043813] Setting up static identity map for 0x200000 - 0x200060 [ 0.046547] brcmstb: biuctrl: MCP: Write pairing already disabled [ 0.048121] CPU1: update cpu_capacity 1024 [ 0.048124] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.048129] CPU1: Spectre v2: using ICIALLU workaround [ 0.048165] CPU1: Spectre BHB: using loop workaround [ 0.049398] CPU2: update cpu_capacity 1024 [ 0.049402] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.049405] CPU2: Spectre v2: using ICIALLU workaround [ 0.049440] CPU2: Spectre BHB: using loop workaround [ 0.050613] CPU3: update cpu_capacity 1024 [ 0.050617] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.050619] CPU3: Spectre v2: using ICIALLU workaround [ 0.050653] CPU3: Spectre BHB: using loop workaround [ 0.050722] Brought up 4 CPUs [ 0.050738] SMP: Total of 4 processors activated (216.00 BogoMIPS). [ 0.050753] CPU: All CPU(s) started in HYP mode.
Does your platform support CPU idle? I see this being triggered during CPU idle transitions ...
It does, but not with an idle state resulting in powering down secondary cores. We do have CPU hotplug with power gating as well as system wide suspend states that result in power gating secondaries and they appear to be working fine.
I use the attached script to randomly cycle hot plug/unplug through each 4 cores and it has been running over 10k cycles.
[ 4.415167] CPU0: Spectre BHB: using loop workaround [ 4.417621] [<c01109a0>] (unwind_backtrace) from [<c010b7ac>] (show_stack+0x10/0x14) [ 4.430291] [<c010b7ac>] (show_stack) from [<c09c2b38>] (dump_stack+0xc0/0xd4) [ 4.437512] [<c09c2b38>] (dump_stack) from [<c011a6c8>] (cpu_v7_spectre_bhb_init+0xd8/0x190) [ 4.445943] [<c011a6c8>] (cpu_v7_spectre_bhb_init) from [<c010dee8>] (cpu_suspend+0xac/0xc8) [ 4.454377] [<c010dee8>] (cpu_suspend) from [<c011e7e4>] (tegra114_idle_power_down+0x74/0x78) [ 4.462898] [<c011e7e4>] (tegra114_idle_power_down) from [<c06d3b44>] (cpuidle_enter_state+0x130/0x524) [ 4.472286] [<c06d3b44>] (cpuidle_enter_state) from [<c0164a30>] (do_idle+0x1b0/0x200) [ 4.480199] [<c0164a30>] (do_idle) from [<c0164d28>] (cpu_startup_entry+0x18/0x1c) [ 4.487762] [<c0164d28>] (cpu_startup_entry) from [<801018cc>] (0x801018cc)
Jon
On 24/05/2022 16:06, Greg Kroah-Hartman wrote:
On Tue, May 24, 2022 at 03:55:58PM +0100, Jon Hunter wrote:
On 24/05/2022 13:09, Greg Kroah-Hartman wrote:
...
I am seeing a boot regression on tegra124-jetson-tk1 and reverting the above commit is fixing the problem. This also appears to impact linux-4.14.y, 4.19.y and 5.4.y.
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 18 boots: 16 pass, 2 fail 18 tests: 18 pass, 0 fail
Linux version: 4.9.316-rc1-gbe4ec3e3faa1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Boot failures: tegra124-jetson-tk1
Odd. This is also in 5.10.y, right? No issues there? Are we missing something?
Actually, the more I look at this, the more I see various intermittent reports with this and it is also impacting the mainline.
The problem is that the commit in question is causing a ton of messages to be printed a boot and this sometimes is causing the boot test to fail because the boot is taking too long. The console shows ...
[ 1233.327547] CPU0: Spectre BHB: using loop workaround [ 1233.327795] CPU1: Spectre BHB: using loop workaround [ 1233.328270] CPU1: Spectre BHB: using loop workaround [ 1233.328700] CPU1: Spectre BHB: using loop workaround [ 1233.355477] CPU2: Spectre BHB: using loop workaround ** 7 printk messages dropped ** [ 1233.366271] CPU0: Spectre BHB: using loop workaround [ 1233.366580] CPU0: Spectre BHB: using loop workaround [ 1233.366815] CPU1: Spectre BHB: using loop workaround [ 1233.405475] CPU1: Spectre BHB: using loop workaround [ 1233.405874] CPU0: Spectre BHB: using loop workaround [ 1233.406041] CPU1: Spectre BHB: using loop workaround ** 1 printk messages dropped **
There is a similar report of this [0] and I believe that we need a similar fix for the above prints as well. I have reported this to Ard [1]. So I am not sure that these Spectre BHB patches are quite ready for stable.
These patches are quite small, and just enable it for this known-broken cpu type.
If there is an issue enabling it for this cpu type, then we can work on that upstream, but there shouldn't be a reason to prevent this from being merged now, especially given that it is supposed to be fixing a known issue.
Yes understand. I have been doing some more testing and with v4.9, this is triggering a boot timeout 100% of the time. So with 20 boots, all 20 timeout. Note the timeout is 2 mins. With v4.14, I saw only 5 out of 20 timeouts and so it would seem that v4.9 is slower to boot in general. I think that the more recent kernels show intermittent timeouts.
We have some verbose logging enabled on this platform, which until now has not been a problem, but I will disable this and that should resolve this for now.
Cheers Jon
On Mon, 23 May 2022 at 22:33, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.316-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
## Build * kernel: 4.9.316-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-4.9.y * git commit: be4ec3e3faa1cfbe1ee62a6f6dc29c1b341a90f0 * git describe: v4.9.315-26-gbe4ec3e3faa1 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.31...
## Test Regressions (compared to v4.9.315) No test regressions found.
## Metric Regressions (compared to v4.9.315) No metric regressions found.
## Test Fixes (compared to v4.9.315) No test fixes found.
## Metric Fixes (compared to v4.9.315) No metric fixes found.
## Test result summary total: 72713, pass: 57877, fail: 683, skip: 11880, xfail: 2273
## Build Summary * arm: 238 total, 238 passed, 0 failed * arm64: 32 total, 32 passed, 0 failed * i386: 18 total, 18 passed, 0 failed * mips: 22 total, 22 passed, 0 failed * sparc: 12 total, 12 passed, 0 failed * x86_64: 31 total, 31 passed, 0 failed
## Test suites summary * fwts * kselftest-android * kselftest-arm64 * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-membarrier * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * kvm-unit-tests * libhugetlbfs * linux-log-parser * log-parser-boot * log-parser-test * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * packetdrill * ssuite * v4l2-compliance * vdso
-- Linaro LKFT https://lkft.linaro.org
Hi!
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
On Mon, May 23, 2022 at 07:03:18PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.316 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 25 May 2022 16:56:55 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 397 pass: 397 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
-
Florian Fainelli -
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Naresh Kamboju -
Pavel Machek -
Shuah Khan