[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230516134447.GB30894@willie-the-truck>
Date: Tue, 16 May 2023 14:44:49 +0100
From: Will Deacon <will@...nel.org>
To: Naresh Kamboju <naresh.kamboju@...aro.org>, broonie@...nel.org
Cc: "open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
linux-stable <stable@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
lkft-triage@...ts.linaro.org,
Catalin Marinas <catalin.marinas@....com>,
Dan Carpenter <dan.carpenter@...aro.org>,
Arnd Bergmann <arnd@...db.de>, Shuah Khan <shuah@...nel.org>,
Anders Roxell <anders.roxell@...aro.org>
Subject: Re: arm64: fp-stress: BUG: KFENCE: memory corruption in
fpsimd_release_task
Hi Naresh,
On Tue, May 16, 2023 at 11:58:40AM +0530, Naresh Kamboju wrote:
> Following kernel BUG noticed while running selftests arm64 fp-stress
> running stable rc kernel versions 6.1.29-rc1 and 6.3.3-rc1.
Is there a known-good build so that we could attempt a bisection?
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
>
> # selftests: arm64: fp-stress
> # TAP version 13
> # 1..80
> # # 8 CPUs, 3 SVE VLs, 3 SME VLs, SME2 absent
> # # Will run for 10s
> ...
>
> # # ZA-VL-32-4: PID: 1091
> # # [ 263.834190]
> ==================================================================
> [ 263.834270] BUG: KFENCE: memory corruption in fpsimd_release_task+0x28/0x50
> [ 263.834270]
> ZA-V[ 263.834419] Corrupted memory at 0x00000000d9c0a375 [ ! ! ! ! !
> ! . . . . . . . . . . ] (in kfence-#158):
> L-64-[ 263.834929] fpsimd_release_task+0x28/0x50
> [ 263.835074] arch_release_task_struct+0x1c/0x30
> [ 263.835221] __put_task_struct+0x164/0x220
> [ 263.835336] delayed_put_task_struct+0x60/0x128
> 4: [ 263.835484] rcu_core+0x318/0x950
> [ 263.835632] rcu_core_si+0x1c/0x30
> [ 263.835770] __do_softirq+0x110/0x3d8
> Stre[ 263.835874] run_ksoftirqd+0x40/0xe0
> [ 263.835994] smpboot_thread_fn+0x1d0/0x260
> [ 263.836105] kthread+0xec/0x190
> [ 263.836221] ret_from_fork+0x10/0x20
> [ 263.836342]
> ami[ 263.836393] kfence-#158: 0x00000000c8819329-0x000000009e00cc22,
> size=546, cache=kmalloc-1k
> [ 263.836393]
> [ 263.836527] allocated by task 1112 on cpu 5 at 252.422888s:
> [ 263.836697] do_sme_acc+0xa8/0x230
> ng m[ 263.836821] el0_sme_acc+0x40/0xa0
> [ 263.836966] el0t_64_sync_handler+0xa8/0xf0
> [ 263.837114] el0t_64_sync+0x190/0x198
Mark -- given that this is an SME allocation, please can you take a look?
I think the implication of the kfence report is that we're writing beyond
the end of 'task->thread.sme_state' at some point and corrupting the
redzone.
There are two reports here, so hopefully it's not too hard to repro.
Will
Powered by blists - more mailing lists