From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CDA293DDDCD for ; Thu, 9 Apr 2026 16:14:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775751246; cv=none; b=JXsmYwEnYUdnhbom1lD/pDiTYKuAy0YfBhLy8bARW/O9pVTpJMqhTznrFYr2oEYy5rvBz2LzBG+Uvc4ciqNjRoI147is1dftXkEFpNzCVsiYLLNzyYVi5mtYGFf0CUGSjLDfyPMifstZdarfLUk6kUb9OWXSYMHcZx8iRjjn+PM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775751246; c=relaxed/simple; bh=nNEalYGkObrBpLChg77VOGw1IGjWphGUuVKtHAliBfk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LRPKfmmPdwgwWQEkbmkez+kuiVntm5MoLVqFRIibzz6ZLnI1rzSgFW2O0pG4gHEVzx3xFMu+cXHEjBumYgMp95M5TI45e4lUE/Zcl+Jz8WkbJPYctd4m8pALbP/Ki3hKCwtZ1SbvAehpN/zn3JjqMFRWPN8I5rmxLdBVjTauu6U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iwzGtKmw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iwzGtKmw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 437EDC116C6; Thu, 9 Apr 2026 16:14:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775751246; bh=nNEalYGkObrBpLChg77VOGw1IGjWphGUuVKtHAliBfk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iwzGtKmwoFRayh3XRWE38wTLU15luyTL8xi7r2dp4/fQJRZV4/vtgYgXbNIDoksjF LjGMzUNnPvhlggkKfYiK4H3PMF42/WaWtCtLXjPycowQY23E9AofdKkEOwwe8iYPFa 3qV/T7WAwhqcwLtGjOoSvhNpfpwuGEC79aBSgKAWLedp0Aw5FrBDUXnvslH5Y2uEjR UcHHKDkrQXOro/H3nil3tLEYXqIjCR3wARwphbLcXVy8BSWDX6aZLEx5OUkRrVWMC+ JqG0X6Rd3s406+TEvFCuzNYZB/F8jPx2RHbPAg9hHfAaO/RedhXVV42Mtu3fukfv2M qktYcYC8Ntgcg== Date: Thu, 9 Apr 2026 09:14:05 -0700 From: Kees Cook To: Jinjie Ruan Cc: catalin.marinas@arm.com, will@kernel.org, oleg@redhat.com, tglx@kernel.org, peterz@infradead.org, luto@kernel.org, wad@chromium.org, linusw@kernel.org, kevin.brodsky@arm.com, yeoreum.yun@arm.com, ldv@strace.io, song@kernel.org, thuth@redhat.com, ryan.roberts@arm.com, mark.rutland@arm.com, ada.coupriediaz@arm.com, anshuman.khandual@arm.com, broonie@kernel.org, liqiang01@kylinos.cn, pengcan@kylinos.cn, mathieu.desnoyers@efficios.com, mingo@kernel.org, edumazet@google.com, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v14 00/10] arm64: entry: Convert to Generic Entry Message-ID: <202604090906.28EA71F63@keescook> References: <20260320102620.1336796-1-ruanjinjie@huawei.com> <174e6d08-4922-f42f-2899-4c5b0df13469@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <174e6d08-4922-f42f-2899-4c5b0df13469@huawei.com> On Thu, Apr 09, 2026 at 02:29:04PM +0800, Jinjie Ruan wrote: > On 2026/3/20 18:26, Jinjie Ruan wrote: > > Currently, x86, Riscv, Loongarch use the Generic Entry which makes > > maintainers' work easier and codes more elegant. arm64 has already > > successfully switched to the Generic IRQ Entry in commit > > b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is > > time to completely convert arm64 to Generic Entry. > > > > The goal is to bring arm64 in line with other architectures that already > > use the generic entry infrastructure, reducing duplicated code and > > making it easier to share future changes in entry/exit paths, such as > > "Syscall User Dispatch" and RSEQ optimizations. > > Just a quick ping to see if this series is good to go. Do I need to > provide a new version rebased on the latest arm64 for-next/generic-entry > branches, or is the current version acceptable? One thing I see is Sashiko's comments on seccomp: https://sashiko.dev/#/patchset/20260320102620.1336796-1-ruanjinjie%40huawei.com where "ret", when not 0 or -1, will override the syscall number. While that's not currently possible, it'd be better to catch that, or rather, avoid the "ret ? : syscall" logic which isn't useful here. "ret" should probably be local to the "if (flags & _TIF_SECCOMP)" scope. -- Kees Cook