From: Mark Rutland <email@example.com> To: Will Deacon <firstname.lastname@example.org> Cc: "Paul E. McKenney" <email@example.com>, Marco Elver <firstname.lastname@example.org>, Steven Rostedt <email@example.com>, Anders Roxell <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Alexander Potapenko <firstname.lastname@example.org>, Dmitry Vyukov <email@example.com>, Jann Horn <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Linux-MM <firstname.lastname@example.org>, kasan-dev <email@example.com>, firstname.lastname@example.org, Peter Zijlstra <email@example.com>, Tejun Heo <firstname.lastname@example.org>, Lai Jiangshan <email@example.com>, firstname.lastname@example.org Subject: Re: linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...) Date: Fri, 20 Nov 2020 10:30:31 +0000 Message-ID: <20201120103031.GB2328@C02TD0UTHF1T.local> (raw) In-Reply-To: <20201119225352.GA5251@willie-the-truck> 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.
next prev parent reply index Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-10 13:53 [PATCH] kfence: Avoid stalling work queue task without allocations Marco Elver 2020-11-10 14:25 ` Dmitry Vyukov 2020-11-10 14:53 ` Marco Elver 2020-11-10 23:23 ` Anders Roxell 2020-11-11 8:29 ` Marco Elver 2020-11-11 13:38 ` Marco Elver 2020-11-11 18:05 ` Steven Rostedt 2020-11-11 18:23 ` Paul E. McKenney 2020-11-11 18:34 ` Marco Elver 2020-11-11 19:21 ` Paul E. McKenney 2020-11-11 20:21 ` Marco Elver 2020-11-12 0:11 ` Paul E. McKenney 2020-11-12 12:49 ` Marco Elver 2020-11-12 16:14 ` Marco Elver 2020-11-12 17:54 ` Paul E. McKenney 2020-11-12 18:12 ` Marco Elver 2020-11-12 20:00 ` Paul E. McKenney 2020-11-13 11:06 ` Marco Elver 2020-11-13 17:20 ` Paul E. McKenney 2020-11-13 17:57 ` Paul E. McKenney 2020-11-17 10:52 ` Marco Elver 2020-11-17 18:29 ` Paul E. McKenney 2020-11-18 22:56 ` Marco Elver 2020-11-18 23:38 ` Paul E. McKenney 2020-11-19 12:53 ` Marco Elver 2020-11-19 15:14 ` Paul E. McKenney 2020-11-19 17:02 ` Marco Elver 2020-11-19 18:48 ` Paul E. McKenney 2020-11-19 19:38 ` linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...) Marco Elver 2020-11-19 21:35 ` Paul E. McKenney 2020-11-19 22:53 ` Will Deacon 2020-11-20 10:30 ` Mark Rutland [this message] 2020-11-20 14:03 ` Marco Elver 2020-11-23 19:32 ` Mark Rutland 2020-11-24 14:03 ` Marco Elver 2020-11-24 15:01 ` Paul E. McKenney 2020-11-24 19:43 ` Mark Rutland 2020-11-24 20:32 ` Steven Rostedt 2020-11-24 19:30 ` Mark Rutland 2020-11-25 9:45 ` Marco Elver 2020-11-25 10:28 ` Mark Rutland 2020-11-20 14:19 ` Marco Elver 2020-11-20 14:39 ` Paul E. McKenney 2020-11-20 15:22 ` Mark Rutland 2020-11-20 17:38 ` Paul E. McKenney 2020-11-20 18:02 ` Mark Rutland 2020-11-20 18:57 ` Paul E. McKenney 2020-11-20 15:26 ` Steven Rostedt 2020-11-20 18:17 ` Marco Elver 2020-11-20 18:57 ` Steven Rostedt 2020-11-20 19:16 ` Steven Rostedt 2020-11-20 19:22 ` Marco Elver 2020-11-20 19:27 ` [PATCH] kfence: Avoid stalling work queue task without allocations Steven Rostedt 2020-11-23 15:27 ` Marco Elver 2020-11-23 16:28 ` Steven Rostedt 2020-11-23 16:36 ` Steven Rostedt 2020-11-23 18:53 ` Marco Elver 2020-11-23 18:42 ` Steven Rostedt 2020-11-24 2:59 ` Boqun Feng 2020-11-24 3:44 ` Paul E. McKenney 2020-11-11 18:21 ` Paul E. McKenney 2020-11-11 15:01 ` Anders Roxell 2020-11-11 15:22 ` Marco Elver
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201120103031.GB2328@C02TD0UTHF1T.local \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git