From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout12.his.huawei.com (canpmsgout12.his.huawei.com [113.46.200.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06F063D34B1 for ; Thu, 9 Jul 2026 06:33:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.227 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783578835; cv=none; b=GhFyT4oZFZQAMOIEwZX4bOrllF5G4lR1fyTvvzF6ebKWb4f9a5vq0UO+VLknh/MRWMj3/niIkwNiTg0NZs5DnPKFF7qZWXzaS+HQYhLfisp2nonALmiwskv/wQLr8U+AwIc2PXkEwaO4pERW2RM6Y6efhfb4n+Svz6CYnaufsG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783578835; c=relaxed/simple; bh=bmVduciFfHoHidzJ0wgbFy55LntqiEjEhPuXLP5IpHA=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Uetb97CQ7iqKHipsDt6jMeOVPTEWAeEHPV63txX4+tNw2pPIQlb5U76a/+m4l088MjHhYGT2FQHf86d41ZSoGyrRAbM/LcqxhlnSh8ryoW5blpXv4RgaG4xPngqW7x68TCuXcn1u6uYP+xXQ1aR3mso0fYNnyoBkkPL6cl7oTok= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=d7cujAJN; arc=none smtp.client-ip=113.46.200.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="d7cujAJN" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=ym4eiUCAjK2DhrxFwWA5wga0jDmwedhuhpvWHZWLYYk=; b=d7cujAJNGo5jnZFiP+W6SrCeNzRmHvUDNU5CNjySnsbZpXbkM4EkSHiThUvpyyyNIzg9gSeOx qUvtVpJRBUtRoWCi9MuMhRGlSwPGZftJR9R52n57KmOeVeychMXwFaniTMFisavWqKH7xbcd3Rk EqkVcI2HEL9A9LS9jTmoaPk= Received: from mail.maildlp.com (unknown [172.19.163.163]) by canpmsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4gwlLt68mKznTXC; Thu, 9 Jul 2026 14:25:10 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 5E9894048B; Thu, 9 Jul 2026 14:33:46 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 9 Jul 2026 14:33:42 +0800 Message-ID: <933879ec-3d41-4ed3-a0e6-e26144540f90@huawei.com> Date: Thu, 9 Jul 2026 14:33:41 +0800 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: Ada Couprie Diaz , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20260629130616.642022-1-ruanjinjie@huawei.com> <20260629130616.642022-19-ruanjinjie@huawei.com> <7dedbe2c-09d9-4d5b-8b70-1977cf526675@arm.com> From: Jinjie Ruan In-Reply-To: <7dedbe2c-09d9-4d5b-8b70-1977cf526675@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To dggpemf500011.china.huawei.com (7.185.36.131) On 6/30/2026 11:14 PM, Ada Couprie Diaz wrote: > 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 ! As Mark suggested, we can decouple the generic entry and syscall_user_dispatch features. First, we can focus on switching to the generic entry, and then implement syscall_user_dispatch. > >> >> 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. Thank you for the review. The related information needs to be improved. > >> 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 > >