From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E45FDD0E6D8 for ; Mon, 21 Oct 2024 09:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=j8kYnh2vcIxO3XNz0ScT/cTXKeSOguVCAeE6X0223Vc=; b=kcvwQxLXQBovaC4X4TxT/qtWbU 2ZwIKw2u+FYc0Z84kKKKkZWzalfJIpBN9OnPutymU8JkhN46lB946wILTDM+U7zVsbJUNga8csQ6y x28qajH+Vqd6zoQrfcjXFBG2806WthGHCz01JOagQ0msHSnTplvM9av5tsDAdUDoIZjklZ37U4twp hICExaJ8dy7r/2ILW0Sw4hnoEGolNTVYuHy7Vx3/LReAly3Q+L+SHO0vGs38CYkqAv4v43XrZIeGH 8dY1Zh5fOMGeTIHkdZbltvWt5yZJNzoZyrNtfwbBg3oFusLApI3ODe2e6cPRgw42slQplhZXKrHOd cdrVCMsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2p3U-00000006lUx-26xE; Mon, 21 Oct 2024 09:50:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t2ozL-00000006kjL-2Pa1 for linux-arm-kernel@lists.infradead.org; Mon, 21 Oct 2024 09:46:13 +0000 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 3E305DA7; Mon, 21 Oct 2024 02:46:38 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B1E0A3F73B; Mon, 21 Oct 2024 02:46:05 -0700 (PDT) Date: Mon, 21 Oct 2024 10:45:56 +0100 From: Mark Rutland To: Jinjie Ruan Cc: catalin.marinas@arm.com, will@kernel.org, oleg@redhat.com, tglx@linutronix.de, peterz@infradead.org, luto@kernel.org, kees@kernel.org, wad@chromium.org, rostedt@goodmis.org, arnd@arndb.de, ardb@kernel.org, broonie@kernel.org, rick.p.edgecombe@intel.com, leobras@redhat.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 0/3] arm64: entry: Convert to generic entry Message-ID: References: <20240629085601.470241-1-ruanjinjie@huawei.com> <0b5e67da-cd23-5159-250a-9f4722655784@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b5e67da-cd23-5159-250a-9f4722655784@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241021_024611_680045_300C47C2 X-CRM114-Status: GOOD ( 21.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Oct 21, 2024 at 04:30:51PM +0800, Jinjie Ruan wrote: > On 2024/10/17 23:25, Mark Rutland wrote: > > On Sat, Jun 29, 2024 at 04:55:58PM +0800, Jinjie Ruan wrote: > > Patch 3 in particular is very hard to follow because several unrelated > > complex systems are updated simultaneously. It would be really nice if > > we could move to the generic sycall code separately from moving the rest > > of the entry code, as the sycall handling code is a particularly > > important ABI concern, and it's difficult to see whether we're making > > ABI changes (accidentaly or knowingly). > > > > Can we split that up (e.g. splitting the generic code first into > > separate entry and syscall files), or are those too tightly coupled for > > that to be possible? > > It will be hard, but I will try to split it, they are surely tightly > coupled which make the 3th patch too big when I try to switch to generic > entry. I'm confused. The point I'm making is don't try to switch to *all* the generic entry code in one go: split the 3rd patch into smaller, logically-distinct separate steps. The 3rd patch shouldn't get larger as you should be changing fewer lines in any individual patch. The regular entry state management (e.g. enter_from_user_mode() and exit_to_user_mode()) is largely separate from the syscall state management, which is pretty clear given syscall_enter_from_user_mode_prepare() and syscall_exit_to_user_mode() wrap the regular entry logic: | noinstr void syscall_enter_from_user_mode_prepare(struct pt_regs *regs) | { | enter_from_user_mode(regs); | instrumentation_begin(); | local_irq_enable(); | instrumentation_end(); | } | __visible noinstr void syscall_exit_to_user_mode(struct pt_regs *regs) | { | instrumentation_begin(); | __syscall_exit_to_user_mode_work(regs); | instrumentation_end(); | exit_to_user_mode(); | } ... and while exit_to_user_mode_prepare() is called by irqentry_exit_to_user_mode(), that's also just a wrapper around exit_to_user_mode(): | noinstr void irqentry_exit_to_user_mode(struct pt_regs *regs) | { | instrumentation_begin(); | exit_to_user_mode_prepare(regs); | instrumentation_end(); | exit_to_user_mode(); | } ... so AFAICT we could move arm64 over to enter_from_user_mode() and exit_to_user_mode() without needing to use any of the generic syscall logic. Doing that first, *then* moving over to the generic syscall handling would be much easier to review/test/bisect, and if there are any ABI issues with the syscall handling in particular (which I think is likely), it will be easier to handle those in isolation. Thanks, Mark.