Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 16 May 2023 14:44:49 +0100
From:   Will Deacon <will@kernel.org>
To:     Naresh Kamboju <naresh.kamboju@linaro.org>, broonie@kernel.org
Cc:     "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>,
        linux-stable <stable@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        lkft-triage@lists.linaro.org,
        Catalin Marinas <catalin.marinas@arm.com>,
        Dan Carpenter <dan.carpenter@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>, Shuah Khan <shuah@kernel.org>,
        Anders Roxell <anders.roxell@linaro.org>
Subject: Re: arm64: fp-stress: BUG: KFENCE: memory corruption in
 fpsimd_release_task
Message-ID: <20230516134447.GB30894@willie-the-truck>
References: <CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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@linaro.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