From: Jiri Olsa <jolsa@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Michael Neuling <mikey@neuling.org>,
Paul Mackerras <paulus@samba.org>
Cc: Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jan Stancek <jstancek@redhat.com>
Subject: Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context
Date: Mon, 3 Oct 2016 15:29:32 +0200 [thread overview]
Message-ID: <20161003132932.GA28947@krava> (raw)
In-Reply-To: <20160923163747.GE5012@twins.programming.kicks-ass.net>
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: [<c0000000000f6a00>] .__atomic_notifier_call_chain+0x0/0x1c0
> > #1: (rcu_read_lock){......}, at: [<c00000000093ac50>] .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
thanks,
jirka
next prev parent reply other threads:[~2016-10-03 13:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 13:55 [PATCH] perf powerpc: Don't call perf_event_disable from atomic context Jiri Olsa
2016-09-23 16:37 ` Peter Zijlstra
2016-10-03 13:29 ` Jiri Olsa [this message]
2016-10-03 13:47 ` Peter Zijlstra
2016-10-04 4:29 ` Michael Ellerman
2016-10-04 7:06 ` Peter Zijlstra
2016-10-10 13:19 ` Will Deacon
2016-10-05 8:09 ` Jiri Olsa
2016-10-05 19:53 ` Jiri Olsa
2016-10-06 7:24 ` Peter Zijlstra
2016-10-06 12:33 ` [PATCHv2] " Jiri Olsa
2016-10-24 12:26 ` Peter Zijlstra
2016-10-24 15:49 ` Jiri Olsa
2016-10-25 6:40 ` [lkp] [perf powerpc] 18d1796d0b: [No primary change] kernel test robot
2016-10-25 9:06 ` Peter Zijlstra
2016-10-26 2:09 ` [LKP] " Huang, Ying
2016-10-26 9:48 ` [PATCHv3] perf powerpc: Don't call perf_event_disable from atomic context Jiri Olsa
2016-10-26 15:12 ` Peter Zijlstra
2016-10-26 15:24 ` Jiri Olsa
2016-10-28 10:10 ` [tip:perf/urgent] perf/powerpc: Don't call perf_event_disable() " tip-bot for Jiri Olsa
2016-10-04 4:08 ` [PATCH] perf powerpc: Don't call perf_event_disable " Michael Ellerman
2016-10-05 8:08 ` Jiri Olsa
2016-10-05 8:21 ` Jan Stancek
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=20161003132932.GA28947@krava \
--to=jolsa@redhat.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=peterz@infradead.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).