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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4447C433EF for ; Tue, 12 Oct 2021 13:26:13 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 6D32A60F23 for ; Tue, 12 Oct 2021 13:26:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6D32A60F23 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+iS9bea/ej3w9i7GcTGli3HLV5WFy7X6FCqSKH5pnQ4=; b=iLG+LZPO48ljdD CslIHYVc3HKXzAs9xF/yEVGwwPyQBVVIj3d5PD+p6dCDLJUJgKjIeY0LuWcc0RmIH66HRxxJmw47M iFQAik7PlQXmVWgMT9CtuoXrQaC1smcRGvLvpdbiRDMPiLzd0weqTqbJZx9LNqkSZlsFZqjtdYV/f q58rg7pa9v53yuPrwVtx5YJDbSrH3V+DLgpwsxHbYTPOOKT3lwiwf9nxCEYwPlcIbbZp9ePEORoUg PJEQXa870sxIX43NtJw6AVhYH1O2M7i/FdcMQCsgQFyx8H1ZCmeN6L4MRfAjs5wZlutcXnsfCmiLq P9OdRBVQH57xzXF7Nt9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1maHkj-00CunZ-U9; Tue, 12 Oct 2021 13:23:34 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1maHfo-00CsBe-H9 for linux-arm-kernel@lists.infradead.org; Tue, 12 Oct 2021 13:18:30 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1634044696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ymITe80mWx73Jpl6DT0uZfy3o7gRcw0Jy8tyHcqTiE8=; b=LgaA3Nn8D5eyiroiMjLQj1ZhZdlUPtCnf/rR857Hlvt8mv5RUmY61YF4hHBKRBYHLcuu/G 6ZMikcEqXcE1GnrbxQhKCF1VQSUMyNDrgz4BzLU5ZU/gCKIgNXI/RVbBa5c/Bsyfm3dVlF KkixShZSQpIlWz6wfjm4YAuLCObFpbqbEyQ772cMxlT4bcbl/KCGQGRyHOp5rP+zitwk1S N/Gagk6koDP600UMSZQhg4GWg5e0y4XRtS1TkWniBwAu2qlgrpk2hrvb8zbESXzX5SZVDk vqnlzBJX/tqy1ZZbMMmue19hCFdLlAJbFqV9I8YFOl/o88Dx91/kw82WsZUwzg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1634044696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ymITe80mWx73Jpl6DT0uZfy3o7gRcw0Jy8tyHcqTiE8=; b=A1bEbvzkMZxpPWGXGbpmn5c5uilUbirjSJukgbchZ/6SfuWjbW6OVRmpiv2Pj4rCXaxU6r +aou9YS2AQw3fBCw== To: Linus Torvalds , Mark Rutland Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Linux Kernel Mailing List , Linux ARM , "Paul E. McKenney" , Peter Zijlstra , Thomas Bogendoerfer , linux-mips@vger.kernel.org Subject: Re: [GIT PULL] arm64 fixes for 5.15-rc5 In-Reply-To: References: <20211011104729.GB1421@C02TD0UTHF1T.local> Date: Tue, 12 Oct 2021 15:18:16 +0200 Message-ID: <87czoacrfr.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211012_061828_960733_65B3AD0C X-CRM114-Status: GOOD ( 34.16 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Linus, On Mon, Oct 11 2021 at 12:54, Linus Torvalds wrote: > On Mon, Oct 11, 2021 at 3:47 AM Mark Rutland wrote: > And so the reason I really hate that patch is that it introduces a new > "different architectures randomly and inexplicably do different > things, and the generic behavior is very different on arm64 than it is > elsewhere". > > That's just the worst kind of hack to me. > > And in this case, it's really *horribly* hard to see what the call > chain is. It all ends up being actively obfuscated and obscured > through that 'handle_arch_irq' function pointer, that is sometimes set > through set_handle_irq(), and sometimes set directly. > > I really think that if the rule is "we can't do accounting in > handle_domain_irq(), because it's too late for arm64", then the fix > really should be to just not do that. > > Move the irq_enter()/irq_exit() to the callers - quite possibly far up > the call chain to the root of it all, and just say "architecture code > needs to do this in the low-level code before calling > handle_arch_irq". That's where it belongs. It's mandatory to have it there for NOHZ_FULL to work correctly vs. instrumentation etc. I've pointed that out back then after we fed the X86 entry code into the mincer and added noinstr sections to keep tracers, BPF and kprobes away from it. Looking at the architectures which "support" that by selecting HAVE_CONTEXT_TRACKING: arch/arm/Kconfig: select HAVE_CONTEXT_TRACKING arch/arm64/Kconfig: select HAVE_CONTEXT_TRACKING arch/csky/Kconfig: select HAVE_CONTEXT_TRACKING arch/mips/Kconfig: select HAVE_CONTEXT_TRACKING arch/powerpc/Kconfig: select HAVE_CONTEXT_TRACKING if PPC64 arch/riscv/Kconfig: select HAVE_CONTEXT_TRACKING arch/sparc/Kconfig: select HAVE_CONTEXT_TRACKING arch/x86/Kconfig: select HAVE_CONTEXT_TRACKING if X86_64 S390 and X86 are (mostly) complete and use the generic entry code. S390 does not even select HAVE_CONTEXT_TRACKING! PPC64 has done quite some work to fix that, but it looks not yet complete. Mark is working on ARM64. There is some effort underway to convert MIPS over to generic entry. The rest needs all the fundamental architecture side changes. > Anyway, it _looks_ to me like the pattern is very simple: > > Step 1: > - remove irq_enter/irq_exit from handle_domain_irq(), move it to all callers. > > This clearly doesn't change anything at all, but also doesn't fix the > problem you have. But it's easy to verify that the code is the same > before-and-after. > > Step 2 is the pattern matching step: > > - if the caller of handle_domain_irq() ends up being a function that > is registered with set_handle_irq(), then we > (a) remove the irq_enter/irq_exit from it > (b) add it to the architectures that use handle_arch_irq. > (c) make sure that if there are other callers of it (not through > handle_arch_irq) we move that irq_enter/irq_exit into them too > > I _suspect_ - but didn't check - that Step 2(c) doesn't actually > exist. But who knows. It only exists with chained handlers, but they do not need that at all because: irq_enter() arch_handle_irq() handle_domain_irq() chained_handler() handle_domain_irq() which is still the same interrupt context and not a nested interrupt. > It really looks like there is a very tight connection between "uses > handle_domain_irq()" and "uses handle_arch_irq/set_handle_irq()". No? Looks like. That might conflict with the MIPS rework though. I don't know how far that came already. Cc'ed the MIPS people. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel