Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4690796pxb; Tue, 28 Sep 2021 01:38:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeZnbi6h3DNJAaZ7mxQWYJJ3QJuMeS17hfnxUB9kqoEcy52t+yYNo/K+UxlcWPYUpI1gLE X-Received: by 2002:a63:b007:: with SMTP id h7mr3439355pgf.443.1632818327827; Tue, 28 Sep 2021 01:38:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632818327; cv=none; d=google.com; s=arc-20160816; b=p/xktIYUERVcnLSYYm0Rhsab2g9q9wRV8JC+uGjNE+XrckJjogTSm0pFasueEcQ9Lo feCDQiQNKgcgkzV+hRLcfuq+ds+YaIFj3JeirCEC+v4q3LRstpkWKBIfKU+TcPVGPtTI o6zhSX2J5ZRwqQzs+ye7sb2MTkVxWbhrNaFRCzZ33Df+cTY9W9qPHW10L3B3fdf2+0Cf rjkJ2IPdaokbMdsZiCdm7aVJh2rPwwn/O1q3oVE41yMx0Jk7CCHiMOnZdgXvI7PuR9jQ kQxEMT3SFlbXdYk7lIGgvl1RjvFWGxiqKgsyDZYDMcuRwi/ccwGFIuT+tzUPZSRUU5pV Rn1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=rZQHWMKZQHvsOZga8zwvhlraTRZFdNGN+sFh34lQDqU=; b=ohiBcgjf2qasdzUR202WxnYhx8GSMI2DV4PpyXlYoK9J3bNLnbI6+80vJUEzkScM78 seIAudJurwPFsnTPXDK70Svb1a5nbUP/hyVDqdhlYZ+OvC+NMfbfkDRVMOamBBKTphe2 2se3Cj//b4kstWN7dr0VZ9x4DcVYNdGmUYH3MLLdqBJgNB/+gD7sLF5g/wGQglNJ6+XF FYfIvl+wAlrYPGJMZts0BRul19CCbViKiBY8puvcwWEccK/t/VOlKGnQde9V3Skx3Tp+ y3yxk/mDkUUaY9JJAo39Zpf3YDch2IFGrfBQ8OUM6zcT4m6LRZnYUFYoHhESjUumfZkP tNeg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z18si26694436pfc.350.2021.09.28.01.38.35; Tue, 28 Sep 2021 01:38:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239630AbhI1Ihe (ORCPT + 99 others); Tue, 28 Sep 2021 04:37:34 -0400 Received: from foss.arm.com ([217.140.110.172]:41448 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239625AbhI1Ihc (ORCPT ); Tue, 28 Sep 2021 04:37:32 -0400 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 6B7466D; Tue, 28 Sep 2021 01:35:53 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.23.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1DCDC3F7B4; Tue, 28 Sep 2021 01:35:49 -0700 (PDT) Date: Tue, 28 Sep 2021 09:35:46 +0100 From: Mark Rutland To: "Paul E. McKenney" Cc: Pingfan Liu , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Marc Zyngier , Joey Gouly , Sami Tolvanen , Julien Thierry , Yuichi Ito , linux-kernel@vger.kernel.org, Sven Schnelle , Vasily Gorbik Subject: Re: [PATCHv2 0/5] arm64/irqentry: remove duplicate housekeeping of Message-ID: <20210928083546.GB1924@C02TD0UTHF1T.local> References: <20210924132837.45994-1-kernelfans@gmail.com> <20210924173615.GA42068@C02TD0UTHF1T.local> <20210924225954.GN880162@paulmck-ThinkPad-P17-Gen-1> <20210927092303.GC1131@C02TD0UTHF1T.local> <20210928000922.GY880162@paulmck-ThinkPad-P17-Gen-1> <20210928083222.GA1924@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210928083222.GA1924@C02TD0UTHF1T.local> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 28, 2021 at 09:32:22AM +0100, Mark Rutland wrote: > On Mon, Sep 27, 2021 at 05:09:22PM -0700, Paul E. McKenney wrote: > > On Mon, Sep 27, 2021 at 10:23:18AM +0100, Mark Rutland wrote: > > > On Fri, Sep 24, 2021 at 03:59:54PM -0700, Paul E. McKenney wrote: > > > > On Fri, Sep 24, 2021 at 06:36:15PM +0100, Mark Rutland wrote: > > > > > [Adding Paul for RCU, s390 folk for entry code RCU semantics] > > > > > > > > > > On Fri, Sep 24, 2021 at 09:28:32PM +0800, Pingfan Liu wrote: > > > > > > After introducing arm64/kernel/entry_common.c which is akin to > > > > > > kernel/entry/common.c , the housekeeping of rcu/trace are done twice as > > > > > > the following: > > > > > > enter_from_kernel_mode()->rcu_irq_enter(). > > > > > > And > > > > > > gic_handle_irq()->...->handle_domain_irq()->irq_enter()->rcu_irq_enter() > > > > > > > > > > > > Besides redundance, based on code analysis, the redundance also raise > > > > > > some mistake, e.g. rcu_data->dynticks_nmi_nesting inc 2, which causes > > > > > > rcu_is_cpu_rrupt_from_idle() unexpected. > > > > > > > > > > Hmmm... > > > > > > > > > > The fundamental questionss are: > > > > > > > > > > 1) Who is supposed to be responsible for doing the rcu entry/exit? > > > > > > > > > > 2) Is it supposed to matter if this happens multiple times? > > > > > > > > > > For (1), I'd generally expect that this is supposed to happen in the > > > > > arch/common entry code, since that itself (or the irqchip driver) could > > > > > depend on RCU, and if that's the case thatn handle_domain_irq() > > > > > shouldn't need to call rcu_irq_enter(). That would be consistent with > > > > > the way we handle all other exceptions. > > > > > > > > > > For (2) I don't know whether the level of nesting is suppoosed to > > > > > matter. I was under the impression it wasn't meant to matter in general, > > > > > so I'm a little surprised that rcu_is_cpu_rrupt_from_idle() depends on a > > > > > specific level of nesting. > > > > > > > > > > >From a glance it looks like this would cause rcu_sched_clock_irq() to > > > > > skip setting TIF_NEED_RESCHED, and to not call invoke_rcu_core(), which > > > > > doesn't sound right, at least... > > > > > > > > > > Thomas, Paul, thoughts? > > > > > > > > It is absolutely required that rcu_irq_enter() and rcu_irq_exit() calls > > > > be balanced. Normally, this is taken care of by the fact that irq_enter() > > > > invokes rcu_irq_enter() and irq_exit() invokes rcu_irq_exit(). Similarly, > > > > nmi_enter() invokes rcu_nmi_enter() and nmi_exit() invokes rcu_nmi_exit(). > > > > > > Sure; I didn't mean to suggest those weren't balanced! The problem here > > > is *nesting*. Due to the structure of our entry code and the core IRQ > > > code, when handling an IRQ we have a sequence: > > > > > > irq_enter() // arch code > > > irq_enter() // irq code > > > > > > < irq handler here > > > > > > > irq_exit() // irq code > > > irq_exit() // arch code > > > > > > ... and if we use something like rcu_is_cpu_rrupt_from_idle() in the > > > middle (e.g. as part of rcu_sched_clock_irq()), this will not give the > > > expected result because of the additional nesting, since > > > rcu_is_cpu_rrupt_from_idle() seems to expect that dynticks_nmi_nesting > > > is only incremented once per exception entry, when it does: > > > > > > /* Are we at first interrupt nesting level? */ > > > nesting = __this_cpu_read(rcu_data.dynticks_nmi_nesting); > > > if (nesting > 1) > > > return false; > > > > > > What I'm trying to figure out is whether that expectation is legitimate, > > > and assuming so, where the entry/exit should happen. > > > > Oooh... > > > > The penalty for fooling rcu_is_cpu_rrupt_from_idle() is that RCU will > > be unable to detect a userspace quiescent state for a non-nohz_full > > CPU. That could result in RCU CPU stall warnings if a user task runs > > continuously on a given CPU for more than 21 seconds (60 seconds in > > some distros). And this can easily happen if the user has a CPU-bound > > thread that is the only runnable task on that CPU. > > > > So, yes, this does need some sort of resolution. > > > > The traditional approach is (as you surmise) to have only a single call > > to irq_enter() on exception entry and only a single call to irq_exit() > > on exception exit. If this is feasible, it is highly recommended. > > Cool; that's roughly what I was expecting / hoping to hear! > > > In theory, we could have that "1" in "nesting > 1" be a constant supplied > > by the architecture (you would want "3" if I remember correctly) but > > in practice could we please avoid this? For one thing, if there is > > some other path into the kernel for your architecture that does only a > > single irq_enter(), then rcu_is_cpu_rrupt_from_idle() just doesn't stand > > a chance. It would need to compare against a different value depending > > on what exception showed up. Even if that cannot happen, it would be > > better if your architecture could remain in blissful ignorance of the > > colorful details of ->dynticks_nmi_nesting manipulations. > > I completely agree. I think it's much harder to keep that in check than > to enforce a "once per architectural exception" policy in the arch code. > > > Another approach would be for the arch code to supply RCU a function that > > it calls. If there is such a function (or perhaps better, if some new > > Kconfig option is enabled), RCU invokes it. Otherwise, it compares to > > "1" as it does now. But you break it, you buy it! ;-) > > I guess we could look at the exception regs and inspect the original > context, but it sounds overkill... > > I think the cleanest thing is to leave this to arch code, and have the > common IRQ code stay well clear. Unfortunately most architectures > (including arch/arm) still need the common IRQ code to handle this, so > we'll have to make that conditional on Kconfig, something like the below > (build+boot tested only). > > If there are no objections, I'll go check who else needs the same > treatment (IIUC at least s390 will), and spin that as a real > patch/series. Ah, looking again this is basically Pinfan's patch 2, so ignore the below, and I'll review Pingfan's patch instead. Thanks, Mark.