From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752016AbcJCNrx (ORCPT ); Mon, 3 Oct 2016 09:47:53 -0400 Received: from merlin.infradead.org ([205.233.59.134]:59134 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751244AbcJCNrx (ORCPT ); Mon, 3 Oct 2016 09:47:53 -0400 Date: Mon, 3 Oct 2016 15:47:40 +0200 From: Peter Zijlstra To: Jiri Olsa Cc: Michael Ellerman , Michael Neuling , Paul Mackerras , Jiri Olsa , lkml , Ingo Molnar , Alexander Shishkin , Jan Stancek Subject: Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context Message-ID: <20161003134740.GC3117@twins.programming.kicks-ass.net> References: <1474466134-21823-1-git-send-email-jolsa@kernel.org> <20160923163747.GE5012@twins.programming.kicks-ass.net> <20161003132932.GA28947@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161003132932.GA28947@krava> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 03, 2016 at 03:29:32PM +0200, Jiri Olsa wrote: > On Fri, Sep 23, 2016 at 06:37:47PM +0200, Peter Zijlstra wrote: > > On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote: > > > The trinity syscall fuzzer triggered following WARN on powerpc: > > > WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 > > > ... > > > NIP [c00000000093aedc] .hw_breakpoint_handler+0x28c/0x2b0 > > > LR [c00000000093aed8] .hw_breakpoint_handler+0x288/0x2b0 > > > Call Trace: > > > [c0000002f7933580] [c00000000093aed8] .hw_breakpoint_handler+0x288/0x2b0 (unreliable) > > > [c0000002f7933630] [c0000000000f671c] .notifier_call_chain+0x7c/0xf0 > > > [c0000002f79336d0] [c0000000000f6abc] .__atomic_notifier_call_chain+0xbc/0x1c0 > > > [c0000002f7933780] [c0000000000f6c40] .notify_die+0x70/0xd0 > > > [c0000002f7933820] [c00000000001a74c] .do_break+0x4c/0x100 > > > [c0000002f7933920] [c0000000000089fc] handle_dabr_fault+0x14/0x48 > > > > > > Followed by lockdep warning: > > > =============================== > > > [ INFO: suspicious RCU usage. ] > > > 4.8.0-rc5+ #7 Tainted: G W > > > ------------------------------- > > > ./include/linux/rcupdate.h:556 Illegal context switch in RCU read-side critical section! > > > > > > other info that might help us debug this: > > > > > > rcu_scheduler_active = 1, debug_locks = 0 > > > 2 locks held by ls/2998: > > > #0: (rcu_read_lock){......}, at: [] .__atomic_notifier_call_chain+0x0/0x1c0 > > > #1: (rcu_read_lock){......}, at: [] .hw_breakpoint_handler+0x0/0x2b0 > > > > > > stack backtrace: > > > CPU: 9 PID: 2998 Comm: ls Tainted: G W 4.8.0-rc5+ #7 > > > Call Trace: > > > [c0000002f7933150] [c00000000094b1f8] .dump_stack+0xe0/0x14c (unreliable) > > > [c0000002f79331e0] [c00000000013c468] .lockdep_rcu_suspicious+0x138/0x180 > > > [c0000002f7933270] [c0000000001005d8] .___might_sleep+0x278/0x2e0 > > > [c0000002f7933300] [c000000000935584] .mutex_lock_nested+0x64/0x5a0 > > > [c0000002f7933410] [c00000000023084c] .perf_event_ctx_lock_nested+0x16c/0x380 > > > [c0000002f7933500] [c000000000230a80] .perf_event_disable+0x20/0x60 > > > [c0000002f7933580] [c00000000093aeec] .hw_breakpoint_handler+0x29c/0x2b0 > > > [c0000002f7933630] [c0000000000f671c] .notifier_call_chain+0x7c/0xf0 > > > [c0000002f79336d0] [c0000000000f6abc] .__atomic_notifier_call_chain+0xbc/0x1c0 > > > [c0000002f7933780] [c0000000000f6c40] .notify_die+0x70/0xd0 > > > [c0000002f7933820] [c00000000001a74c] .do_break+0x4c/0x100 > > > [c0000002f7933920] [c0000000000089fc] handle_dabr_fault+0x14/0x48 > > > > > > > Well, that lockdep warning only says you should not be taking sleeping > > locks while holding rcu_read_lock(), which is true. It does not say the > > context you're doing this is cannot sleep. > > > > I'm not familiar enough with the PPC stuff to tell if the DIE_DABR_MATCH > > trap context is atomic or not and this Changelog doesn't tell me. > > > > Anybody? > > ping So I think all the DIE notifiers are atomic, which means this would indeed be the thing to do. That said, I didn't see anything similar on other BP implementations. So it would be good to also explain why PPC needs this in the first place.