Re: [PATCH v3 1/4] arm64/gcs: release GCS on failed fork

[Catalin Marinas]

On Wed, Oct 28, 2026 at 12:43:12PM -0300, Iván Ezequiel Rodriguez wrote:
> copy_thread() can map a CLONE_VM GCS and still return 0. A later
> copy_process() failure calls exit_thread(), but arm64 did not
> implement it, so the VMA stayed in the parent's mm. Wire
> HAVE_EXIT_THREAD to gcs_free().
> 
> x86 already does this via exit_thread() -> shstk_free(). The separate
> x86 TLS leak is different: copy_thread() itself fails after the
> alloc, so copy_process() skips exit_thread().

Is the x86 TLS leak relevant to arm64?

[...]

> @@ -503,6 +517,8 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
>  
>  		p->thread.cpu_context.x19 = (unsigned long)args->fn;
>  		p->thread.cpu_context.x20 = (unsigned long)args->fn_arg;
> +		/* No user GCS alloc here; drop inherited tracking for CLONE_VM. */
> +		gcs_reset_thread(p);

My LLM run noticed that this fixes another problem, unrelated to the
failed fork: io_uring and vhost workers are created with args->fn and
CLONE_VM and they inherit gcs_base/gcs_size from the creating task
through arch_dup_task_struct(). Without this reset, a worker exiting
normally unmaps the parent task's GCS.

I was wondering whether to have a separate one-line commit for the
worker thread case but I think I'll just add a comment in the commit
log, keep things simple.

-- 
Catalin