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(-)
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.gz
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 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
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.9.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
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.gz > 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.315-26-gbe4ec3e3faa1 ## 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 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.gz
> 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
--
nvpublic
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.gz > > 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.osipenko@collabora.com/T/ [1] https://lore.kernel.org/linux-arm-kernel/a589f56d-a0e1-328d-e4be-9427342d46b8@nvidia.com/ -- nvpublic
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 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 -- nvpublic
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. -- Florian
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 -- nvpublic
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 > -- Florian
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.gz > 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
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.gz > 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> -- Florian
© 2016 - 2024 Red Hat, Inc.