From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (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 1903A3290DC for ; Fri, 10 Apr 2026 02:09:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775786990; cv=none; b=IDFXPL147zqA5Jk8ZSiIQTAnTsE4A3X1qqsLtMT62B7qO/HQ9kNR3xRKymS+LorxTVUyvlSzFdrvxi0rvXPHdTlN/rugSK/fVqMEHcOv01HhxHM6w9jXcmV6hWv2J1mupkaMyrOJ26QOreOyJH/xa2fDGS31oNZs9ZkRvBhtLlY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775786990; c=relaxed/simple; bh=GtOYMfvOgEVfE1EN6RwSExT3gPeu0KX0gkBmAFiiyC8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=PUTpbfU9klGFM5/TdS3hFiYSwXtKDM2tWd+W/vqRStNXBY2QGwyf+4PGZZvs2ndCgnuLk/7uBmwME1HDxusfJyKUUb3YKUYVDGCw+Z0kocVDC7LrcCBX0hzx2t5cduJnSkB7WpH+ldQxodO77cUmadhlh+xluUXuYmQcdkYYzy4= 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=p9iDYCoq; arc=none smtp.client-ip=113.46.200.226 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="p9iDYCoq" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=bClVIpICpxUFZrpNzPacQNh3LCyGQ394bBULoiY+YP4=; b=p9iDYCoqVcNmsHO3LIMvAiJkZG/J+5qrpcuJZLi531Z/4IsNBdqP3+28GkgwJ2W5XczkIk2y2 o290saBAWSN+9M0xjlk3SXxd1vxjHFAUQLnJRw6BwuXwtlbieIs8TfRSdLm0617du7xI8B7zKtS b5NNrHKzHVQIMKWUBsB/gBI= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4fsKpK60HCzKm5G; Fri, 10 Apr 2026 10:03:21 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id C9C0C40573; Fri, 10 Apr 2026 10:09:38 +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; Fri, 10 Apr 2026 10:09:37 +0800 Message-ID: Date: Fri, 10 Apr 2026 10:09:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH v14 00/10] arm64: entry: Convert to Generic Entry Content-Language: en-US To: Kees Cook CC: , , , , , , , , , , , , , , , , , , , , , , , , , References: <20260320102620.1336796-1-ruanjinjie@huawei.com> <174e6d08-4922-f42f-2899-4c5b0df13469@huawei.com> <202604090906.28EA71F63@keescook> From: Jinjie Ruan In-Reply-To: <202604090906.28EA71F63@keescook> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To dggpemf500011.china.huawei.com (7.185.36.131) On 2026/4/10 0:14, Kees Cook wrote: > 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. It might be better to fix the identical logic in the generic entry first? then align arm64. Doing otherwise would cause the "arm64: entry: Convert to generic entry" patch to create an unnecessary discrepancy. >