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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DB74C5519F for ; Fri, 20 Nov 2020 10:30:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 96E8722255 for ; Fri, 20 Nov 2020 10:30:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96E8722255 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9E496B0036; Fri, 20 Nov 2020 05:30:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4F1F6B005C; Fri, 20 Nov 2020 05:30:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D16BD6B005D; Fri, 20 Nov 2020 05:30:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 990936B0036 for ; Fri, 20 Nov 2020 05:30:40 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 26BC2180AD830 for ; Fri, 20 Nov 2020 10:30:40 +0000 (UTC) X-FDA: 77504427840.01.swing28_2211dba2734a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 0A45710045BF2 for ; Fri, 20 Nov 2020 10:30:40 +0000 (UTC) X-HE-Tag: swing28_2211dba2734a X-Filterd-Recvd-Size: 5068 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 10:30:39 +0000 (UTC) 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 6C0C21042; Fri, 20 Nov 2020 02:30:38 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.27.176]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AAB813F70D; Fri, 20 Nov 2020 02:30:34 -0800 (PST) Date: Fri, 20 Nov 2020 10:30:31 +0000 From: Mark Rutland To: Will Deacon Cc: "Paul E. McKenney" , Marco Elver , Steven Rostedt , Anders Roxell , Andrew Morton , Alexander Potapenko , Dmitry Vyukov , Jann Horn , Linux Kernel Mailing List , Linux-MM , kasan-dev , rcu@vger.kernel.org, Peter Zijlstra , Tejun Heo , Lai Jiangshan , linux-arm-kernel@lists.infradead.org Subject: Re: linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...) Message-ID: <20201120103031.GB2328@C02TD0UTHF1T.local> References: <20201117182915.GM1437@paulmck-ThinkPad-P72> <20201118225621.GA1770130@elver.google.com> <20201118233841.GS1437@paulmck-ThinkPad-P72> <20201119125357.GA2084963@elver.google.com> <20201119151409.GU1437@paulmck-ThinkPad-P72> <20201119170259.GA2134472@elver.google.com> <20201119184854.GY1437@paulmck-ThinkPad-P72> <20201119193819.GA2601289@elver.google.com> <20201119213512.GB1437@paulmck-ThinkPad-P72> <20201119225352.GA5251@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119225352.GA5251@willie-the-truck> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 19, 2020 at 10:53:53PM +0000, Will Deacon wrote: > On Thu, Nov 19, 2020 at 01:35:12PM -0800, Paul E. McKenney wrote: > > On Thu, Nov 19, 2020 at 08:38:19PM +0100, Marco Elver wrote: > > > On Thu, Nov 19, 2020 at 10:48AM -0800, Paul E. McKenney wrote: > > > > On Thu, Nov 19, 2020 at 06:02:59PM +0100, Marco Elver wrote: > > > > [ . . . ] > > > > > > > I can try bisection again, or reverting some commits that might be > > > > > suspicious? But we'd need some selection of suspicious commits. > > > > > > > > The report claims that one of the rcu_node ->lock fields is held > > > > with interrupts enabled, which would indeed be bad. Except that all > > > > of the stack traces that it shows have these locks held within the > > > > scheduling-clock interrupt handler. Now with the "rcu: Don't invoke > > > > try_invoke_on_locked_down_task() with irqs disabled" but without the > > > > "sched/core: Allow try_invoke_on_locked_down_task() with irqs disabled" > > > > commit, I understand why. With both, I don't see how this happens. > > > > > > I'm at a loss, but happy to keep bisecting and trying patches. I'm also > > > considering: > > > > > > Is it the compiler? Probably not, I tried 2 versions of GCC. > > > > > > Can we trust lockdep to precisely know IRQ state? I know there's > > > been some recent work around this, but hopefully we're not > > > affected here? > > > > > > Is QEMU buggy? > > > > > > > At this point, I am reduced to adding lockdep_assert_irqs_disabled() > > > > calls at various points in that code, as shown in the patch below. > > > > > > > > At this point, I would guess that your first priority would be the > > > > initial bug rather than this following issue, but you never know, this > > > > might well help diagnose the initial bug. > > > > > > I don't mind either way. I'm worried deadlocking the whole system might > > > be worse. > > > > Here is another set of lockdep_assert_irqs_disabled() calls on the > > off-chance that they actually find something. > > FWIW, arm64 is known broken wrt lockdep and irq tracing atm. Mark has been > looking at that and I think he is close to having something workable. > > Mark -- is there anything Marco and Paul can try out? I initially traced some issues back to commit: 044d0d6de9f50192 ("lockdep: Only trace IRQ edges") ... and that change of semantic could cause us to miss edges in some cases, but IIUC mostly where we haven't done the right thing in exception entry/return. I don't think my patches address this case yet, but my WIP (currently just fixing user<->kernel transitions) is at: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/irq-fixes I'm looking into the kernel<->kernel transitions now, and I know that we mess up RCU management for a small window around arch_cpu_idle, but it's not immediately clear to me if either of those cases could cause this report. Thanks, Mark.