* [PATCH 5.15 142/159] test_firmware: fix the memory leak of the allocated firmware buffer
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
@ 2023-06-07 20:17 ` Greg Kroah-Hartman
2023-06-07 23:55 ` [PATCH 5.15 000/159] 5.15.116-rc1 review Florian Fainelli
` (9 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2023-06-07 20:17 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Mirsad Goran Todorovac,
Dan Carpenter, Takashi Iwai, Luis Chamberlain, Russ Weight,
Tianfei zhang, Christophe JAILLET, Zhengchao Shao, Colin Ian King,
linux-kernel, Kees Cook, Scott Branden, linux-kselftest
From: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
commit 48e156023059e57a8fc68b498439832f7600ffff upstream.
The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:
[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#
Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.
The cause of the leak is the following:
request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Tianfei zhang <tianfei.zhang@intel.com>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Zhengchao Shao <shaozhengchao@huawei.com>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/test_firmware.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -41,6 +41,7 @@ struct test_batched_req {
bool sent;
const struct firmware *fw;
const char *name;
+ const char *fw_buf;
struct completion completion;
struct task_struct *task;
struct device *dev;
@@ -143,8 +144,14 @@ static void __test_release_all_firmware(
for (i = 0; i < test_fw_config->num_requests; i++) {
req = &test_fw_config->reqs[i];
- if (req->fw)
+ if (req->fw) {
+ if (req->fw_buf) {
+ kfree_const(req->fw_buf);
+ req->fw_buf = NULL;
+ }
release_firmware(req->fw);
+ req->fw = NULL;
+ }
}
vfree(test_fw_config->reqs);
@@ -586,6 +593,8 @@ static ssize_t trigger_request_store(str
mutex_lock(&test_fw_mutex);
release_firmware(test_firmware);
+ if (test_fw_config->reqs)
+ __test_release_all_firmware();
test_firmware = NULL;
rc = request_firmware(&test_firmware, name, dev);
if (rc) {
@@ -686,6 +695,8 @@ static ssize_t trigger_async_request_sto
mutex_lock(&test_fw_mutex);
release_firmware(test_firmware);
test_firmware = NULL;
+ if (test_fw_config->reqs)
+ __test_release_all_firmware();
rc = request_firmware_nowait(THIS_MODULE, 1, name, dev, GFP_KERNEL,
NULL, trigger_async_request_cb);
if (rc) {
@@ -728,6 +739,8 @@ static ssize_t trigger_custom_fallback_s
mutex_lock(&test_fw_mutex);
release_firmware(test_firmware);
+ if (test_fw_config->reqs)
+ __test_release_all_firmware();
test_firmware = NULL;
rc = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOUEVENT, name,
dev, GFP_KERNEL, NULL,
@@ -790,6 +803,8 @@ static int test_fw_run_batch_request(voi
test_fw_config->buf_size);
if (!req->fw)
kfree(test_buf);
+ else
+ req->fw_buf = test_buf;
} else {
req->rc = test_fw_config->req_firmware(&req->fw,
req->name,
@@ -845,6 +860,7 @@ static ssize_t trigger_batched_requests_
req->fw = NULL;
req->idx = i;
req->name = test_fw_config->name;
+ req->fw_buf = NULL;
req->dev = dev;
init_completion(&req->completion);
req->task = kthread_run(test_fw_run_batch_request, req,
@@ -944,6 +960,7 @@ ssize_t trigger_batched_requests_async_s
for (i = 0; i < test_fw_config->num_requests; i++) {
req = &test_fw_config->reqs[i];
req->name = test_fw_config->name;
+ req->fw_buf = NULL;
req->fw = NULL;
req->idx = i;
init_completion(&req->completion);
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
2023-06-07 20:17 ` [PATCH 5.15 142/159] test_firmware: fix the memory leak of the allocated firmware buffer Greg Kroah-Hartman
@ 2023-06-07 23:55 ` Florian Fainelli
2023-06-08 1:26 ` Shuah Khan
` (8 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Florian Fainelli @ 2023-06-07 23:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow
On 6/7/23 13:15, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +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/v5.x/stable-review/patch-5.15.116-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-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tseted on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
2023-06-07 20:17 ` [PATCH 5.15 142/159] test_firmware: fix the memory leak of the allocated firmware buffer Greg Kroah-Hartman
2023-06-07 23:55 ` [PATCH 5.15 000/159] 5.15.116-rc1 review Florian Fainelli
@ 2023-06-08 1:26 ` Shuah Khan
2023-06-08 7:20 ` Chris Paterson
` (7 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Shuah Khan @ 2023-06-08 1:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, Shuah Khan
On 6/7/23 14:15, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +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/v5.x/stable-review/patch-5.15.116-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-5.15.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
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2023-06-08 1:26 ` Shuah Khan
@ 2023-06-08 7:20 ` Chris Paterson
2023-06-08 11:28 ` Bagas Sanjaya
` (6 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Chris Paterson @ 2023-06-08 7:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable@vger.kernel.org
Cc: patches@lists.linux.dev, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux@roeck-us.net, shuah@kernel.org, patches@kernelci.org,
lkft-triage@lists.linaro.org, pavel@denx.de, jonathanh@nvidia.com,
f.fainelli@gmail.com, sudipm.mukherjee@gmail.com,
srw@sladewatkins.net, rwarsow@gmx.de
Hello Greg,
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: Wednesday, June 7, 2023 9:15 PM
>
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +0000.
> Anything received after that time might be too late.
CIP configurations built and booted okay with Linux 5.15.116-rc1 (00621f2608ac):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/893074039
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/commits/linux-5.15.y
Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
Kind regards, Chris
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2023-06-08 7:20 ` Chris Paterson
@ 2023-06-08 11:28 ` Bagas Sanjaya
2023-06-08 14:05 ` Naresh Kamboju
` (5 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Bagas Sanjaya @ 2023-06-08 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
On Wed, Jun 07, 2023 at 10:15:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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.
>
Successfully compiled and installed bindeb-pkgs on my computer (Acer
Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2023-06-08 11:28 ` Bagas Sanjaya
@ 2023-06-08 14:05 ` Naresh Kamboju
2023-06-08 15:44 ` Harshit Mogalapalli
` (4 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Naresh Kamboju @ 2023-06-08 14:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Thu, 8 Jun 2023 at 02:27, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +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/v5.x/stable-review/patch-5.15.116-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-5.15.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: 5.15.116-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.15.y
* git commit: 00621f2608ac31643168c86e902c21a017ffe3b1
* git describe: v5.15.114-196-g00621f2608ac
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.114-196-g00621f2608ac
## Test Regressions (compared to v5.15.114)
## Metric Regressions (compared to v5.15.114)
## Test Fixes (compared to v5.15.114)
## Metric Fixes (compared to v5.15.114)
## Test result summary
total: 108256, pass: 91348, fail: 3032, skip: 13715, xfail: 161
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 117 total, 116 passed, 1 failed
* arm64: 45 total, 43 passed, 2 failed
* i386: 35 total, 32 passed, 3 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 27 total, 26 passed, 1 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 11 passed, 1 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 38 total, 36 passed, 2 failed
## Test suites summary
* boot
* fwts
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* 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-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2023-06-08 14:05 ` Naresh Kamboju
@ 2023-06-08 15:44 ` Harshit Mogalapalli
2023-06-08 22:04 ` Ron Economos
` (3 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Harshit Mogalapalli @ 2023-06-08 15:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, Vegard Nossum, Darren Kenny
Hi Greg,
On 08/06/23 1:45 am, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +0000.
> Anything received after that time might be too late.
>
No problems seen on x86_64 and aarch64.
Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Thanks,
Harshit
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.116-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-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2023-06-08 15:44 ` Harshit Mogalapalli
@ 2023-06-08 22:04 ` Ron Economos
2023-06-09 8:37 ` Sudip Mukherjee (Codethink)
` (2 subsequent siblings)
10 siblings, 0 replies; 20+ messages in thread
From: Ron Economos @ 2023-06-08 22:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
On 6/7/23 1:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +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/v5.x/stable-review/patch-5.15.116-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-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <re@w6rz.net>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2023-06-08 22:04 ` Ron Economos
@ 2023-06-09 8:37 ` Sudip Mukherjee (Codethink)
2023-06-09 11:06 ` Guenter Roeck
2023-06-09 16:17 ` Jon Hunter
10 siblings, 0 replies; 20+ messages in thread
From: Sudip Mukherjee (Codethink) @ 2023-06-09 8:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli, srw, rwarsow
Hi Greg,
On Wed, Jun 07, 2023 at 10:15:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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.
Build test (gcc version 12.2.1 20230511):
mips: 62 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/3807
[2]. https://openqa.qa.codethink.co.uk/tests/3823
[3]. https://openqa.qa.codethink.co.uk/tests/3824
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2023-06-09 8:37 ` Sudip Mukherjee (Codethink)
@ 2023-06-09 11:06 ` Guenter Roeck
2023-06-09 18:42 ` Guenter Roeck
2023-06-09 16:17 ` Jon Hunter
10 siblings, 1 reply; 20+ messages in thread
From: Guenter Roeck @ 2023-06-09 11:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
On Wed, Jun 07, 2023 at 10:15:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 499 pass: 498 fail: 1
Failed tests:
arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
The test failure is spurious and not new. I observe it randomly on
multi_v7_defconfig builds, primarily on npcm platforms. There is no error
message, just a stalled boot. I have been trying to bisect for a while,
but I have not been successful so far. No immediate concern; I just wanted
to mention it in case someone else hits the same or a similar problem.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-09 11:06 ` Guenter Roeck
@ 2023-06-09 18:42 ` Guenter Roeck
2023-06-09 19:06 ` Linus Torvalds
2023-06-10 19:23 ` Pavel Machek
0 siblings, 2 replies; 20+ messages in thread
From: Guenter Roeck @ 2023-06-09 18:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, Thomas Gleixner, Ido Schimmel
Hi,
On Fri, Jun 09, 2023 at 04:07:00AM -0700, Guenter Roeck wrote:
> On Wed, Jun 07, 2023 at 10:15:03PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.116 release.
> > There are 159 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 Fri, 09 Jun 2023 20:07:31 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 155 pass: 155 fail: 0
> Qemu test results:
> total: 499 pass: 498 fail: 1
> Failed tests:
> arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
>
> The test failure is spurious and not new. I observe it randomly on
> multi_v7_defconfig builds, primarily on npcm platforms. There is no error
> message, just a stalled boot. I have been trying to bisect for a while,
> but I have not been successful so far. No immediate concern; I just wanted
> to mention it in case someone else hits the same or a similar problem.
>
I managed to revise my bisect script sufficiently enough to get reliable
results. It looks like the culprit is commit 503e554782c9 (" debugobject:
Ensure pool refill (again)"); see bisect log below. Bisect on four
different systems all have the same result. After reverting this patch,
I do not see the problem anymore (again, confirmed on four different
systems). If anyone has an idea how to debug this, please let me know.
I'll be happy to give it a try.
Thanks,
Guenter
---
# bad: [7349e40704a0209a2af8b37fa876322209de9684] Linux 5.15.116
# good: [d214f240b0f61480f9dbc4384cef03f6a55e5d03] Linux 5.15.100
git bisect start 'HEAD' 'v5.15.100'
# good: [11c58a0c1937c157dbdf82d5ab634d68c99f3098] x86/MCE/AMD: Use an u64 for bank_map
git bisect good 11c58a0c1937c157dbdf82d5ab634d68c99f3098
# bad: [e9c5fc4f3f35e769932158a7347ec245be5cefb9] drm/amd/display: Use DC_LOG_DC in the trasform pixel function
git bisect bad e9c5fc4f3f35e769932158a7347ec245be5cefb9
# good: [3dc3a86b88bda88b4ac859b18559385f02932e78] SMB3: Close deferred file handles in case of handle lease break
git bisect good 3dc3a86b88bda88b4ac859b18559385f02932e78
# bad: [b13e20cc58e438b2d3473147329fe3fe80e3bc09] perf stat: Separate bperf from bpf_profiler
git bisect bad b13e20cc58e438b2d3473147329fe3fe80e3bc09
# bad: [43b2f7d690697182beed6f71aa57b7249d3cfc9c] ubifs: Fix memory leak in do_rename
git bisect bad 43b2f7d690697182beed6f71aa57b7249d3cfc9c
# good: [8444b46e163aa9559a0af0381a1d230ec4146eb2] mtd: core: fix nvmem error reporting
git bisect good 8444b46e163aa9559a0af0381a1d230ec4146eb2
# good: [f76fcb9d43ec014ac4a1bb983768696d5b032df9] dm flakey: fix a crash with invalid table line
git bisect good f76fcb9d43ec014ac4a1bb983768696d5b032df9
# bad: [aa6ff950f875ebc9a01dc53666a1af17004924ad] arm64: dts: qcom: sdm845: correct dynamic power coefficients - again
git bisect bad aa6ff950f875ebc9a01dc53666a1af17004924ad
# good: [06106efa20f74a14674ae53def7abaddd851f7e2] perf auxtrace: Fix address filter entire kernel size
git bisect good 06106efa20f74a14674ae53def7abaddd851f7e2
# bad: [503e554782c916aec553f790298564a530cf1778] debugobject: Ensure pool refill (again)
git bisect bad 503e554782c916aec553f790298564a530cf1778
# good: [6b84832966a094a1b8305b1a42a4f157a3121258] perf intel-pt: Fix CYC timestamps after standalone CBR
git bisect good 6b84832966a094a1b8305b1a42a4f157a3121258
# first bad commit: [503e554782c916aec553f790298564a530cf1778] debugobject: Ensure pool refill (again)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-09 18:42 ` Guenter Roeck
@ 2023-06-09 19:06 ` Linus Torvalds
2023-06-09 19:31 ` Guenter Roeck
2023-06-10 19:23 ` Pavel Machek
1 sibling, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2023-06-09 19:06 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, akpm, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
On Fri, Jun 9, 2023 at 11:42 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> I managed to revise my bisect script sufficiently enough to get reliable
> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
> Ensure pool refill (again)"); see bisect log below. Bisect on four
> different systems all have the same result. After reverting this patch,
> I do not see the problem anymore (again, confirmed on four different
> systems).
Does this happen on mainline too? It's commit 0af462f19e63 in the upstream tree.
It was in 6.4-rc1, and I see a clean result from you at least for
-rc2, so for some reason it sounds like upstream is ok. But I don't
really see why that would be the case...
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-09 19:06 ` Linus Torvalds
@ 2023-06-09 19:31 ` Guenter Roeck
2023-06-12 9:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 20+ messages in thread
From: Guenter Roeck @ 2023-06-09 19:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, akpm, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
On 6/9/23 12:06, Linus Torvalds wrote:
> On Fri, Jun 9, 2023 at 11:42 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> I managed to revise my bisect script sufficiently enough to get reliable
>> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
>> Ensure pool refill (again)"); see bisect log below. Bisect on four
>> different systems all have the same result. After reverting this patch,
>> I do not see the problem anymore (again, confirmed on four different
>> systems).
>
> Does this happen on mainline too? It's commit 0af462f19e63 in the upstream tree.
>
> It was in 6.4-rc1, and I see a clean result from you at least for
> -rc2, so for some reason it sounds like upstream is ok. But I don't
> really see why that would be the case...
>
I see the problem only in v5.15.y, to the point where it is almost
impossible to get a clean test of all arm-v7 systems. Affected are
npcm (Nuvoton) boards (kudo-bmc, quanta-gsj, npcm750-evb) as well as
orangepi-pc. I don't see it in any other branch or with any other
platform/architecture.
Mainline is fine; I have not seen any problems since -rc2.
I have no idea what is going on either, only that I can reliably
reproduce the problem (and of course it disappears if CONFIG_DEBUG_OBJECTS
is disabled).
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-09 19:31 ` Guenter Roeck
@ 2023-06-12 9:13 ` Greg Kroah-Hartman
0 siblings, 0 replies; 20+ messages in thread
From: Greg Kroah-Hartman @ 2023-06-12 9:13 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Torvalds, stable, patches, linux-kernel, akpm, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
On Fri, Jun 09, 2023 at 12:31:04PM -0700, Guenter Roeck wrote:
> On 6/9/23 12:06, Linus Torvalds wrote:
> > On Fri, Jun 9, 2023 at 11:42 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > I managed to revise my bisect script sufficiently enough to get reliable
> > > results. It looks like the culprit is commit 503e554782c9 (" debugobject:
> > > Ensure pool refill (again)"); see bisect log below. Bisect on four
> > > different systems all have the same result. After reverting this patch,
> > > I do not see the problem anymore (again, confirmed on four different
> > > systems).
> >
> > Does this happen on mainline too? It's commit 0af462f19e63 in the upstream tree.
> >
> > It was in 6.4-rc1, and I see a clean result from you at least for
> > -rc2, so for some reason it sounds like upstream is ok. But I don't
> > really see why that would be the case...
> >
>
> I see the problem only in v5.15.y, to the point where it is almost
> impossible to get a clean test of all arm-v7 systems. Affected are
> npcm (Nuvoton) boards (kudo-bmc, quanta-gsj, npcm750-evb) as well as
> orangepi-pc. I don't see it in any other branch or with any other
> platform/architecture.
>
> Mainline is fine; I have not seen any problems since -rc2.
>
> I have no idea what is going on either, only that I can reliably
> reproduce the problem (and of course it disappears if CONFIG_DEBUG_OBJECTS
> is disabled).
Ok, I've reverted it from 5.15.y for now until this is figured out.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-09 18:42 ` Guenter Roeck
2023-06-09 19:06 ` Linus Torvalds
@ 2023-06-10 19:23 ` Pavel Machek
2023-06-10 21:14 ` Guenter Roeck
1 sibling, 1 reply; 20+ messages in thread
From: Pavel Machek @ 2023-06-10 19:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
Hi!
> > Build results:
> > total: 155 pass: 155 fail: 0
> > Qemu test results:
> > total: 499 pass: 498 fail: 1
> > Failed tests:
> > arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
> >
> > The test failure is spurious and not new. I observe it randomly on
> > multi_v7_defconfig builds, primarily on npcm platforms. There is no error
> > message, just a stalled boot. I have been trying to bisect for a while,
> > but I have not been successful so far. No immediate concern; I just wanted
> > to mention it in case someone else hits the same or a similar problem.
> >
>
> I managed to revise my bisect script sufficiently enough to get reliable
> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
> Ensure pool refill (again)"); see bisect log below. Bisect on four
> different systems all have the same result. After reverting this patch,
> I do not see the problem anymore (again, confirmed on four different
> systems). If anyone has an idea how to debug this, please let me know.
> I'll be happy to give it a try.
You may want to comment out debug_objects_fill_pool() in
debug_object_activate or debug_object_assert_init to see which one is
causing the failure...
CONFIG_PREEMPT_RT is disabled for you, right? (Should 5.15 even have
that option?)
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-10 19:23 ` Pavel Machek
@ 2023-06-10 21:14 ` Guenter Roeck
2023-06-11 15:14 ` Guenter Roeck
0 siblings, 1 reply; 20+ messages in thread
From: Guenter Roeck @ 2023-06-10 21:14 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
Hi,
On 6/10/23 12:23, Pavel Machek wrote:
> Hi!
>
>>> Build results:
>>> total: 155 pass: 155 fail: 0
>>> Qemu test results:
>>> total: 499 pass: 498 fail: 1
>>> Failed tests:
>>> arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
>>>
>>> The test failure is spurious and not new. I observe it randomly on
>>> multi_v7_defconfig builds, primarily on npcm platforms. There is no error
>>> message, just a stalled boot. I have been trying to bisect for a while,
>>> but I have not been successful so far. No immediate concern; I just wanted
>>> to mention it in case someone else hits the same or a similar problem.
>>>
>>
>> I managed to revise my bisect script sufficiently enough to get reliable
>> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
>> Ensure pool refill (again)"); see bisect log below. Bisect on four
>> different systems all have the same result. After reverting this patch,
>> I do not see the problem anymore (again, confirmed on four different
>> systems). If anyone has an idea how to debug this, please let me know.
>> I'll be happy to give it a try.
>
> You may want to comment out debug_objects_fill_pool() in
> debug_object_activate or debug_object_assert_init to see which one is
> causing the failure...
>
> CONFIG_PREEMPT_RT is disabled for you, right? (Should 5.15 even have
> that option?)
>
CONFIG_PREEMPT_RT is disabled (it depends on ARCH_SUPPORTS_RT which is not
enabled by any architecture in v5.15.y).
The added call in debug_object_activate() triggers the problem.
Any idea what to do about it or how to debug it further ?
Thanks,
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-10 21:14 ` Guenter Roeck
@ 2023-06-11 15:14 ` Guenter Roeck
2023-06-12 1:12 ` Guenter Roeck
0 siblings, 1 reply; 20+ messages in thread
From: Guenter Roeck @ 2023-06-11 15:14 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
On 6/10/23 14:14, Guenter Roeck wrote:
> Hi,
>
> On 6/10/23 12:23, Pavel Machek wrote:
>> Hi!
>>
>>>> Build results:
>>>> total: 155 pass: 155 fail: 0
>>>> Qemu test results:
>>>> total: 499 pass: 498 fail: 1
>>>> Failed tests:
>>>> arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
>>>>
>>>> The test failure is spurious and not new. I observe it randomly on
>>>> multi_v7_defconfig builds, primarily on npcm platforms. There is no error
>>>> message, just a stalled boot. I have been trying to bisect for a while,
>>>> but I have not been successful so far. No immediate concern; I just wanted
>>>> to mention it in case someone else hits the same or a similar problem.
>>>>
>>>
>>> I managed to revise my bisect script sufficiently enough to get reliable
>>> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
>>> Ensure pool refill (again)"); see bisect log below. Bisect on four
>>> different systems all have the same result. After reverting this patch,
>>> I do not see the problem anymore (again, confirmed on four different
>>> systems). If anyone has an idea how to debug this, please let me know.
>>> I'll be happy to give it a try.
>>
>> You may want to comment out debug_objects_fill_pool() in
>> debug_object_activate or debug_object_assert_init to see which one is
>> causing the failure...
>>
>> CONFIG_PREEMPT_RT is disabled for you, right? (Should 5.15 even have
>> that option?)
>>
>
> CONFIG_PREEMPT_RT is disabled (it depends on ARCH_SUPPORTS_RT which is not
> enabled by any architecture in v5.15.y).
>
> The added call in debug_object_activate() triggers the problem.
> Any idea what to do about it or how to debug it further ?
>
I did some more debugging. The call to debug_object_activate()
from debug_hrtimer_activate() causes the immediate problem, and the
call from debug_timer_activate() causes a second (less likely) problem,
where the stall is seen during reboot.
In other words, the problem is (only) seen if DEBUG_OBJECTS_TIMERS
is enabled.
Guenter
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-11 15:14 ` Guenter Roeck
@ 2023-06-12 1:12 ` Guenter Roeck
0 siblings, 0 replies; 20+ messages in thread
From: Guenter Roeck @ 2023-06-12 1:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, Thomas Gleixner, Ido Schimmel
On 6/11/23 08:14, Guenter Roeck wrote:
> On 6/10/23 14:14, Guenter Roeck wrote:
>> Hi,
>>
>> On 6/10/23 12:23, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> Build results:
>>>>> total: 155 pass: 155 fail: 0
>>>>> Qemu test results:
>>>>> total: 499 pass: 498 fail: 1
>>>>> Failed tests:
>>>>> arm:kudo-bmc:multi_v7_defconfig:npcm:usb0.1:nuvoton-npcm730-kudo:rootfs
>>>>>
>>>>> The test failure is spurious and not new. I observe it randomly on
>>>>> multi_v7_defconfig builds, primarily on npcm platforms. There is no error
>>>>> message, just a stalled boot. I have been trying to bisect for a while,
>>>>> but I have not been successful so far. No immediate concern; I just wanted
>>>>> to mention it in case someone else hits the same or a similar problem.
>>>>>
>>>>
>>>> I managed to revise my bisect script sufficiently enough to get reliable
>>>> results. It looks like the culprit is commit 503e554782c9 (" debugobject:
>>>> Ensure pool refill (again)"); see bisect log below. Bisect on four
>>>> different systems all have the same result. After reverting this patch,
>>>> I do not see the problem anymore (again, confirmed on four different
>>>> systems). If anyone has an idea how to debug this, please let me know.
>>>> I'll be happy to give it a try.
>>>
>>> You may want to comment out debug_objects_fill_pool() in
>>> debug_object_activate or debug_object_assert_init to see which one is
>>> causing the failure...
>>>
>>> CONFIG_PREEMPT_RT is disabled for you, right? (Should 5.15 even have
>>> that option?)
>>>
>>
>> CONFIG_PREEMPT_RT is disabled (it depends on ARCH_SUPPORTS_RT which is not
>> enabled by any architecture in v5.15.y).
>>
>> The added call in debug_object_activate() triggers the problem.
>> Any idea what to do about it or how to debug it further ?
>>
>
> I did some more debugging. The call to debug_object_activate()
> from debug_hrtimer_activate() causes the immediate problem, and the
> call from debug_timer_activate() causes a second (less likely) problem,
> where the stall is seen during reboot.
>
> In other words, the problem is (only) seen if DEBUG_OBJECTS_TIMERS
> is enabled.
>
Bisect log between v5.15 and v6.1 below. The fix is all but impossible to backport,
and I still have no idea what is actually going on. I think I'll just disable
DEBUG_OBJECTS_TIMERS in affected tests of v5.15.y.
Guenter
---
# fixed: [830b3c68c1fb1e9176028d02ef86f3cf76aa2476] Linux 6.1
# broken: [8bb7eca972ad531c9b149c0a51ab43a417385813] Linux 5.15
git bisect start 'v6.1' 'v5.15'
# broken: [7fa2e481ff2fee20e0338d98489eb9f513ada45f] Merge branch 'big-tcp'
git bisect broken 7fa2e481ff2fee20e0338d98489eb9f513ada45f
# fixed: [9e2e5ea3b28f81512c792f30729edb1db0c21f6a] Merge tag 'usb-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect fixed 9e2e5ea3b28f81512c792f30729edb1db0c21f6a
# fixed: [4ad680f083ec360e0991c453e18a38ed9ae500d7] Merge tag 'staging-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect fixed 4ad680f083ec360e0991c453e18a38ed9ae500d7
# fixed: [2518f226c60d8e04d18ba4295500a5b0b8ac7659] Merge tag 'drm-next-2022-05-25' of git://anongit.freedesktop.org/drm/drm
git bisect fixed 2518f226c60d8e04d18ba4295500a5b0b8ac7659
# broken: [fea3043314f30a87ca04fd1219661810600e256f] Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect broken fea3043314f30a87ca04fd1219661810600e256f
# broken: [f8122500a039abeabfff41b0ad8b6a2c94c1107d] Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next
git bisect broken f8122500a039abeabfff41b0ad8b6a2c94c1107d
# fixed: [7e062cda7d90543ac8c7700fc7c5527d0c0f22ad] Merge tag 'net-next-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect fixed 7e062cda7d90543ac8c7700fc7c5527d0c0f22ad
# broken: [9fa87dd23251574a29cf948fd16cf39075762f3e] Merge tag 'linux-can-next-for-5.19-20220523' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
git bisect broken 9fa87dd23251574a29cf948fd16cf39075762f3e
# fixed: [88a618920e9baabc1780479e2fbb68e5551d0563] Merge tag 'docs-5.19' of git://git.lwn.net/linux
git bisect fixed 88a618920e9baabc1780479e2fbb68e5551d0563
# broken: [fdaf9a5840acaab18694a19e0eb0aa51162eeeed] Merge tag 'folio-5.19' of git://git.infradead.org/users/willy/pagecache
git bisect broken fdaf9a5840acaab18694a19e0eb0aa51162eeeed
# broken: [164f9fcb21cc9a144ca9ebcf85b00c49537f6be2] docs/ja_JP/SubmittingPatches: Suggest the use of scripts/get_maintainer.pl
git bisect broken 164f9fcb21cc9a144ca9ebcf85b00c49537f6be2
# broken: [2e17ce1106e04a7f3a83796ec623881487f75dd3] Merge tag 'slab-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
git bisect broken 2e17ce1106e04a7f3a83796ec623881487f75dd3
# fixed: [701850dc0c31bfadf75a0a74af7d2c97859945ec] printk, tracing: fix console tracepoint
git bisect fixed 701850dc0c31bfadf75a0a74af7d2c97859945ec
# broken: [1fc0ca9e0db61882208650b3603071e9f4b5cfee] printk: add con_printk() macro for console details
git bisect broken 1fc0ca9e0db61882208650b3603071e9f4b5cfee
# broken: [2bb2b7b57f81255c13f4395ea911d6bdc70c9fe2] printk: add functions to prefer direct printing
git bisect broken 2bb2b7b57f81255c13f4395ea911d6bdc70c9fe2
# fixed: [8e274732115f63c1d09136284431b3555bd5cc56] printk: extend console_lock for per-console locking
git bisect fixed 8e274732115f63c1d09136284431b3555bd5cc56
# fixed: [09c5ba0aa2fcfdadb17d045c3ee6f86d69270df7] printk: add kthread console printers
git bisect fixed 09c5ba0aa2fcfdadb17d045c3ee6f86d69270df7
# first fixed commit: [09c5ba0aa2fcfdadb17d045c3ee6f86d69270df7] printk: add kthread console printers
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 5.15 000/159] 5.15.116-rc1 review
2023-06-07 20:15 [PATCH 5.15 000/159] 5.15.116-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2023-06-09 11:06 ` Guenter Roeck
@ 2023-06-09 16:17 ` Jon Hunter
10 siblings, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2023-06-09 16:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, linux-tegra, stable
On Wed, 07 Jun 2023 22:15:03 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.116 release.
> There are 159 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 Fri, 09 Jun 2023 20:07:31 +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/v5.x/stable-review/patch-5.15.116-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-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 fail
Linux version: 5.15.116-rc1-g00621f2608ac
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 20+ messages in thread