[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39b003bc-df89-4e0b-929e-2c42354aaa86@sirena.org.uk>
Date: Tue, 17 Oct 2023 15:03:24 +0100
From: Mark Brown <broonie@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>,
lkft-triage@...ts.linaro.org,
linux-stable <stable@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Marc Zyngier <maz@...nel.org>
Subject: Re: selftests: ftrace: Internal error: Oops: sve_save_state
On Tue, Oct 17, 2023 at 02:42:01PM +0100, Mark Rutland wrote:
> So unless sve_alloc() failed, at the instant the IRQ was taken:
> * `task->thread.sve_state` should be non-NULL
> * `task->thread_info.flags & TIF_SVE` should be 0
> ... so if `task->thread.sve_state` becomes NULL, I wonder if we end up
> accidentally blatting that as part of the context switch? I can't immedaitely
> see how/
We're possibly missing a fpsimd_bind_task_to_cpu() somewhere since all
the hilarity with KVM means that we don't use the task_struct to save
state, though the task that's taking the SVE trap shouldn't be impacted
there if it didn't set TIF_SVE yet. There *is* a window where we have
TIF_SVE set but didn't yet do the rebind but that should be in a preempt
disabled section.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists