[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ad1408f2-8a6d-4299-b986-0bacc58ad388@sirena.org.uk>
Date: Wed, 19 Mar 2025 15:03:06 +0000
From: Mark Brown <broonie@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Jeremy Linton <jeremy.linton@....com>,
linux-trace-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, mhiramat@...nel.org,
oleg@...hat.com, peterz@...radead.org, acme@...nel.org,
namhyung@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, thiago.bauermann@...aro.org,
yury.khrustalev@....com, kristina.martsenko@....com,
liaochang1@...wei.com, catalin.marinas@....com, will@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] arm64/gcs: task_gcs_el0_enable() should use passed
task
On Wed, Mar 19, 2025 at 02:26:26PM +0000, Mark Rutland wrote:
> On Tue, Mar 18, 2025 at 03:48:35PM -0500, Jeremy Linton wrote:
> if (!task_gcs_el0_enabled(p))
> return 0;
> p->thread.gcs_el0_mode = current->thread.gcs_el0_mode;
> Either that later assignment is redundant, or copy_thread_gcs() was
> accidentally relying upon task_gcs_el0_enabled() reading from 'current'
> rather than 'p', and this change opens up another bug...
copy_thread_gcs() looks buggy here - we should move the allocation of
the new stack to the bottom of the function after the assignments. Like
you say it does currently work due to the check of the source thread.
The other users are the prctl and signal code which always work with
current and the check to see if we should do a GCSB DSYNC in
gcs_thread_switch() which currently misses a sync if switching from a
non-GCS to GCS task.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists