From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 402902D3220 for ; Tue, 30 Jun 2026 15:14:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782832470; cv=none; b=oj823nFXJ3zDknrIfw9w3+JNiS3Xx5nOSioETA7ZYuxIybJ4FlJHHxV1N+gQ81h+a1QkF5k5Qz6v96fBPEykDKitE9bc5hFMbwEgDdHj7EogxzFmcPLod+ayze0m1/hagkYKUSZQk1aLv1ZmLrf1PjRg0URb7OmZygFJZAt1ZOc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782832470; c=relaxed/simple; bh=9xr72TE+igvLVlNPFv4xah9LNvL/PNLDVngoXViM8xA=; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc: In-Reply-To:Content-Type; b=ZFNPzp1vIfzeqcaQIIGIPQ7zA+R5CV3dlYRa+u4K/YVGniWUdSMuiOyB91sle0QxpMnIvcoHjauGkUz/ZeyCae6ZvZBmQs2KoFlR3U+AqyxP8lO0gFS8xXKVhC1JFQRkFeBFLpjg2H95s/NAXB+ZkwIDX46d8hchgDKonGTFXdk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=rBelcefg; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="rBelcefg" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0F6CB2EDF; Tue, 30 Jun 2026 08:14:23 -0700 (PDT) Received: from [10.2.213.21] (e137867.arm.com [10.2.213.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1E603F66F; Tue, 30 Jun 2026 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782832467; bh=9xr72TE+igvLVlNPFv4xah9LNvL/PNLDVngoXViM8xA=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From; b=rBelcefghtcBpRKZUtImOBOvZpcpzuS66Tdd9PtWjH1lndhmKvXc5oRUJnVvzYSLi kUWFuS08wtKxVHnqnfcNbzXSNYrA86n3SBraqSsgsolS2NfrxBB54e2Pq+31suSTHG 4RM5sxZ9cWKEA9YxYOaYTctt7dUPMUTWUkQK+Mec= Message-ID: <7dedbe2c-09d9-4d5b-8b70-1977cf526675@arm.com> Date: Tue, 30 Jun 2026 16:14:13 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v16 18/18] arm64: vdso: Expose sigreturn address on vdso to the kernel To: Jinjie Ruan , kevin.brodsky@arm.com References: <20260629130616.642022-1-ruanjinjie@huawei.com> <20260629130616.642022-19-ruanjinjie@huawei.com> From: Ada Couprie Diaz Cc: Ada Couprie Diaz , oleg@redhat.com, richard.henderson@linaro.org, mattst88@gmail.com, linmag7@gmail.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org, kees@kernel.org, guoren@kernel.org, chenhuacai@kernel.org, kernel@xen0n.name, geert@linux-m68k.org, tsbogend@alpha.franken.de, James.Bottomley@HansenPartnership.com, deller@gmx.de, maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, glaubitz@physik.fu-berlin.de, richard@nod.at, anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net, luto@kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, chris@zankel.net, jcmvbkbc@gmail.com, peterz@infradead.org, wad@chromium.org, thuth@redhat.com, mark.rutland@arm.com, linusw@kernel.org, yeoreum.yun@arm.com, song@kernel.org, james.morse@arm.com, anshuman.khandual@arm.com, broonie@kernel.org, liqiang01@kylinos.cn, pengcan@kylinos.cn, ryan.roberts@arm.com, yangtiezhu@loongson.cn, sshegde@linux.ibm.com, mchauras@linux.ibm.com, austin.kim@lge.com, jchrist@linux.ibm.com, arnd@arndb.de, thomas.weissschuh@linutronix.de, sohil.mehta@intel.com, andrew.cooper3@citrix.com, jgross@suse.com, kas@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Content-Language: en-US, en-GB, fr Organization: Arm Ltd. In-Reply-To: <20260629130616.642022-19-ruanjinjie@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jinjie, On 29/06/2026 14:06, Jinjie Ruan wrote: > Syscall User Dispatch (SUD) requires the signal trampoline code to not be > intercepted. This is necessary to support returning with a locked selector > while avoiding infinite recursion back into the signal handler. Thanks for splitting this out, I find it is much clearer that way ! However, this should definitely be earlier in the series As I mentioned in my comment in v15, Syscall User Dispatch only depends on `CONFIG_GENERIC_ENTRY`, so enabling generic entry for arm64 in patch 16 also enables Syscall User Dispatch. Given that this series adds a weak default function returning false for `arch_syscall_is_vdso_sigreturn()` before enabling generic entry for arm64 in patch 16,  patch 16 and 17 have a potentially broken SUD enabled, as we do not check for those sigreturns yet. I think shuffling this patch back just before converting to generic entry should be OK ! > > Implement arch_syscall_is_vdso_sigreturn() for arm64 to support this > exclusion mechanism. For native 64-bit tasks, it checks whether the current > PC matches the 'svc #0' instruction inside the vDSO sigreturn trampoline. > > SYM_CODE_START(__kernel_rt_sigreturn) > mov x8, #__NR_rt_sigreturn > svc #0 > SYM_CODE_END(__kernel_rt_sigreturn) Maybe add `arch/arm64/kernel/vdso/sigreturn.S` to mention where this snippet comes from ? > > For COMPAT tasks, it verifies if the instruction falls within > the architecture's 'sigpage' range, allowing the kernel to safely bypass > dispatching syscalls originating from these areas back to userspace. I think this might benefit from a bit more details or clarity on the "why" of the COMPAT handling : there is a vDSO page for COMPAT tasks, but COMPAT signal handlers have their own dedicated page, `sigpage`, which serves the same purpose and is handled similarly, so it needs to be checked as well. Hopefully that is correct... Would you find that relevant information to add ? Pinging @Kevin Brodsky on that as well. > Suggested-by: Kevin Brodsky > Suggested-by: kemal > Signed-off-by: Jinjie Ruan > --- > arch/arm64/include/asm/elf.h | 1 + > arch/arm64/kernel/vdso.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+) Otherwise this looks good to me, great to have more context with the change ! Thanks, Ada