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 CACA02D541B for ; Fri, 27 Mar 2026 01:27:26 +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=1774574849; cv=none; b=iv4CtrqnxHv5dNOq00NR9FMyUrwwnUj8/tigK7/X10NZ6lSuK5gBwx/xWMt6PqAj5Jy626OL3rinWa2jkS4aPM5gPRQeh7ITj9RRK7VIUO7UmwLnJEmxLDedssXHZ/eRh42vsZo9naFv4rxwBQjE8cZkClJQH0qXOY7neI212jQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774574849; c=relaxed/simple; bh=YOPHd8bt2z9hUb33wrzrzEoyrXqPv9xcRb1veJnkFwo=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=eUzPjZvbPs8mDHv3t8V3pxPwRyF4eGXm9IlDw/NTET/1gZv4xS4H9HpLGV0aTHt3lAW6uz4STUwnB5Dek1tZUqwQHpnZfZB9V3OONhJIYMEkcWuBzyci5w/cnREqqZTQoS1bTwXG1IgZR+so0k+Cwick/Q6Jgo74QCGsasoufVs= 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=SV4LXG+l; 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="SV4LXG+l" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=kNTiOwptuWCFL75qrnEQ7468cCcswAjztz8iN5Iz26g=; b=SV4LXG+l7Gm2hE7ibi5DUm21Osr/F4BoY61mfe9nIsNF9cRvZUfYRfWvJOyPHRCXQhBR+hNCU TY8u2En1cl58v6N+EF8yQ4ILKyrqsmYixdENQmOP2eoMNRtETnJoSPIbU6ZbsjzK+Y6isFySyja U+sgEJ+KUg3JW05IEMJradw= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4fhjXC5GGBzKmTj; Fri, 27 Mar 2026 09:21:15 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 2E2AA40563; Fri, 27 Mar 2026 09:27:24 +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, 27 Mar 2026 09:27:22 +0800 Message-ID: Date: Fri, 27 Mar 2026 09:27:20 +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 1/2] arm64/entry: Fix involuntary preemption exception masking Content-Language: en-US To: Mark Rutland , Thomas Gleixner CC: , , , , , , , References: <20260320113026.3219620-1-mark.rutland@arm.com> <20260320113026.3219620-2-mark.rutland@arm.com> <87eclek0mb.ffs@tglx> <87341ujwl4.ffs@tglx> <87fr5six4d.ffs@tglx> <87ecl7gbeu.ffs@tglx> From: Jinjie Ruan In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To dggpemf500011.china.huawei.com (7.185.36.131) On 2026/3/27 2:11, Mark Rutland wrote: > On Wed, Mar 25, 2026 at 04:46:01PM +0100, Thomas Gleixner wrote: >> On Wed, Mar 25 2026 at 11:03, Mark Rutland wrote: >>> On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote: >>> I *think* what would work for us is we could split some of the exit >>> handling (including involuntary preemption) into a "prepare" step, as we >>> have for return to userspace. That way, arm64 could handle exiting >>> something like: >>> >>> local_irq_disable(); >>> irqentry_exit_prepare(); // new, all generic logic >>> local_daif_mask(); >>> arm64_exit_to_kernel_mode() { >>> ... >>> irqentry_exit(); // ideally irqentry_exit_to_kernel_mode(). >>> ... >>> } >>> >>> ... and other architectures can use a combined exit_to_kernel_mode() (or >>> whatever we call that), which does both, e.g. >>> >>> // either noinstr, __always_inline, or a macro >>> void irqentry_prepare_and_exit(void) >> >> That's a bad idea as that would require to do a full kernel rename of >> all existing irqentry_exit() users. >> >>> { >>> irqentry_exit_prepare(); >>> irqentry_exit(); >>> } >> >> Aside of the naming that should work. > > Thanks for confirming! > > I've pushed a (very early, WIP) draft to > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework The patch also looks good to me. Looking forward to seeing this move forward. > > ... which is missing commit messages, comments, etc, but seems to work. > > I'll see about getting that tested, cleaned up, and on-list. > > Mark. >