From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 AF00C34028D for ; Wed, 8 Apr 2026 01:40:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775612450; cv=none; b=brecUc0kvZsPmbGKXdaWjZPe4Git1MMtiBcltw1sjbuJA6gPjJcp7F1b3OFFVihzmH48WCajE02DpSKU2VYDgpDisjzqzIoK4RQmh1cU2jMQgiRlux8uVseIj6eEPcsNA7ci+5l1mG8AqYHSqPrP2b7owt69Ovggt7vrSCESh08= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775612450; c=relaxed/simple; bh=hjXGwYWrMjH7YiK7xK9Ani7ZaohjG0ht6LZnp5OmGmk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=i09yjRlj9ENwWN3Uq5FWSOqNxOjhrbomYMjzWjGdIAjoHIn9T7kZofjDjhPngkESBKcWoNI3OYTtRwyBxJOLxp48+iQ24DTj2LGDYHYyjSP28SaVePaxzrGXOS0h31R2EkhCkgiboyrncpd8L+Ev81Hk141Jg7mhuJSPdxiJlqs= 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=5pZBsSTZ; arc=none smtp.client-ip=113.46.200.218 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="5pZBsSTZ" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=aDrgltfSK6mSCyyVg4mYTUVCd6VbQDkka8UiJiTC4TU=; b=5pZBsSTZ85GTD8pSLxVdtCz2C6SY2LU8nF0stKwKaoUT0wbxzEVk/OlTQH3CpACV8rieJeyiP RdS3EQM2NWPfJsdepU2Y/l8MrrPH3dEC0lVu8wtAX0Dw8T2QBmqPSfeZuKiD+wKx1ruMFIySP6O yGW1kTkmQKI+ujnjve/KRR8= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4fr5G806RfzpTBG; Wed, 8 Apr 2026 09:34:40 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id A34AB4048F; Wed, 8 Apr 2026 09:40:39 +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; Wed, 8 Apr 2026 09:40:38 +0800 Message-ID: <66eb3cfc-fdb9-def0-00be-3c1dd3c2884d@huawei.com> Date: Wed, 8 Apr 2026 09:40:36 +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 05/10] entry: Split preemption from irqentry_exit_to_kernel_mode() Content-Language: en-US To: Mark Rutland , , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner CC: , , , , References: <20260407131650.3813777-1-mark.rutland@arm.com> <20260407131650.3813777-6-mark.rutland@arm.com> From: Jinjie Ruan In-Reply-To: <20260407131650.3813777-6-mark.rutland@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To dggpemf500011.china.huawei.com (7.185.36.131) On 2026/4/7 21:16, Mark Rutland wrote: > Some architecture-specific work needs to be performed between the state > management for exception entry/exit and the "real" work to handle the > exception. For example, arm64 needs to manipulate a number of exception > masking bits, with different exceptions requiring different masking. > > Generally this can all be hidden in the architecture code, but for arm64 > the current structure of irqentry_exit_to_kernel_mode() makes this > particularly difficult to handle in a way that is correct, maintainable, > and efficient. > > The gory details are described in the thread surrounding: > > https://lore.kernel.org/lkml/acPAzdtjK5w-rNqC@J2N7QTR9R3/ > > The summary is: > > * Currently, irqentry_exit_to_kernel_mode() handles both involuntary > preemption AND state management necessary for exception return. > > * When scheduling (including involuntary preemption), arm64 needs to > have all arm64-specific exceptions unmasked, though regular interrupts > must be masked. > > * Prior to the state management for exception return, arm64 needs to > mask a number of arm64-specific exceptions, and perform some work with > these exceptions masked (with RCU watching, etc). > > While in theory it is possible to handle this with a new arch_*() hook > called somewhere under irqentry_exit_to_kernel_mode(), this is fragile > and complicated, and doesn't match the flow used for exception return to > user mode, which has a separate 'prepare' step (where preemption can > occur) prior to the state management. > > To solve this, refactor irqentry_exit_to_kernel_mode() to match the > style of {irqentry,syscall}_exit_to_user_mode(), moving preemption logic > into a new irqentry_exit_to_kernel_mode_preempt() function, and moving > state management in a new irqentry_exit_to_kernel_mode_after_preempt() > function. The existing irqentry_exit_to_kernel_mode() is left as a > caller of both of these, avoiding the need to modify existing callers. > > There should be no functional change as a result of this patch. > > Signed-off-by: Mark Rutland > Cc: Andy Lutomirski > Cc: Catalin Marinas > Cc: Jinjie Ruan > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Vladimir Murzin > Cc: Will Deacon > --- > include/linux/irq-entry-common.h | 26 +++++++++++++++++++++----- > 1 file changed, 21 insertions(+), 5 deletions(-) > > Thomas/Peter/Andy, as mentioned on IRC, I haven't created kerneldoc > comments for these new functions because the existing comments don't > seem all that consistent (e.g. for user mode vs kernel mode), and I > suspect we want to rewrite them all in one go for wider consistency. > > I'm happy to respin this, or to follow-up with that as per your > preference. > > Mark. > > diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h > index 2206150e526d8..24830baa539c6 100644 > --- a/include/linux/irq-entry-common.h > +++ b/include/linux/irq-entry-common.h > @@ -421,10 +421,18 @@ static __always_inline irqentry_state_t irqentry_enter_from_kernel_mode(struct p > return ret; > } > > -static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state) > +static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, irqentry_state_t state) > { > - lockdep_assert_irqs_disabled(); > + if (regs_irqs_disabled(regs) || state.exit_rcu) > + return; > + > + if (IS_ENABLED(CONFIG_PREEMPTION)) > + irqentry_exit_cond_resched(); > +} > > +static __always_inline void > +irqentry_exit_to_kernel_mode_after_preempt(struct pt_regs *regs, irqentry_state_t state) > +{ > if (!regs_irqs_disabled(regs)) { > /* > * If RCU was not watching on entry this needs to be done > @@ -443,9 +451,6 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i > } > > instrumentation_begin(); > - if (IS_ENABLED(CONFIG_PREEMPTION)) > - irqentry_exit_cond_resched(); > - > /* Covers both tracing and lockdep */ > trace_hardirqs_on(); > instrumentation_end(); > @@ -459,6 +464,17 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i > } > } > > +static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state) > +{ > + lockdep_assert_irqs_disabled(); > + > + instrumentation_begin(); > + irqentry_exit_to_kernel_mode_preempt(regs, state); > + instrumentation_end(); > + > + irqentry_exit_to_kernel_mode_after_preempt(regs, state); > +} Reviewed-by: Jinjie Ruan > + > /** > * irqentry_enter - Handle state tracking on ordinary interrupt entries > * @regs: Pointer to pt_regs of interrupted context