From: Mark Rutland <mark.rutland@arm.com> To: Fengguang Wu <fengguang.wu@intel.com>, Peter Zijlstra <peterz@infradead.org> Cc: Peter Zijlstra <peterz@infradead.org>, LKP <lkp@01.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [perf] WARNING: CPU: 0 PID: 1457 at kernel/events/core.c:890 add_event_to_ctx() Date: Sun, 25 Jan 2015 15:56:33 +0000 [thread overview] Message-ID: <20150125155633.GA22257@leverpostej> (raw) In-Reply-To: <20150125043428.GA6109@wfg-t540p.sh.intel.com> On Sun, Jan 25, 2015 at 04:34:28AM +0000, Fengguang Wu wrote: > Greetings, Hi Fengguang, Thanks very much for the report. > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core > > commit d26bb7f73a2881f2412c340a27438b185f0cc3dc > Author: Mark Rutland <mark.rutland@arm.com> > AuthorDate: Wed Jan 7 15:01:54 2015 +0000 > Commit: Peter Zijlstra <peterz@infradead.org> > CommitDate: Fri Jan 23 15:17:56 2015 +0100 > > perf: decouple unthrottling and rotating [...] What seems to be happening is: * An event is created in the context of task A on CPU0. As the task's hw context is empty of events, we call perf_pmu_ctx_activate. This adds the cpuctx of the relevant HW PMU to the active_ctx_list. Note that we checked the task's ctx for emptiness, then added the PMU's hw context. * An event is created (as a result of a clone()) in the context of task B on CPU0, and we do the same thing, finding the ctx empty of events we add the HW PMU's cpuctx to the active_ctx_list. As it's already in there, the WARN_ON(!list_empty(&cpuctx->active_ctx_list)) explodes. So I guess what we actually want to do is to turn the active_ctx list into a list of perf_event_contexts rather than perf_event_cpu_contexts, and add/remove from the list when a context is scheduled in/out (or updated empty<->nonempty). That way we remove chances for erroneous add/remove, and we don't need to treat task and CPU contexts separately in perf_event_task_tick. I managed to get the reproducer running on a box at home, so I'll spin a potential fix against that for a while, and send that out if I don't see explosions. Peter, I guess you'll drop this patch for now? Thanks, Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: lkp@lists.01.org Subject: Re: [perf] WARNING: CPU: 0 PID: 1457 at kernel/events/core.c:890 add_event_to_ctx() Date: Sun, 25 Jan 2015 15:56:33 +0000 [thread overview] Message-ID: <20150125155633.GA22257@leverpostej> (raw) In-Reply-To: <20150125043428.GA6109@wfg-t540p.sh.intel.com> [-- Attachment #1: Type: text/plain, Size: 1835 bytes --] On Sun, Jan 25, 2015 at 04:34:28AM +0000, Fengguang Wu wrote: > Greetings, Hi Fengguang, Thanks very much for the report. > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core > > commit d26bb7f73a2881f2412c340a27438b185f0cc3dc > Author: Mark Rutland <mark.rutland@arm.com> > AuthorDate: Wed Jan 7 15:01:54 2015 +0000 > Commit: Peter Zijlstra <peterz@infradead.org> > CommitDate: Fri Jan 23 15:17:56 2015 +0100 > > perf: decouple unthrottling and rotating [...] What seems to be happening is: * An event is created in the context of task A on CPU0. As the task's hw context is empty of events, we call perf_pmu_ctx_activate. This adds the cpuctx of the relevant HW PMU to the active_ctx_list. Note that we checked the task's ctx for emptiness, then added the PMU's hw context. * An event is created (as a result of a clone()) in the context of task B on CPU0, and we do the same thing, finding the ctx empty of events we add the HW PMU's cpuctx to the active_ctx_list. As it's already in there, the WARN_ON(!list_empty(&cpuctx->active_ctx_list)) explodes. So I guess what we actually want to do is to turn the active_ctx list into a list of perf_event_contexts rather than perf_event_cpu_contexts, and add/remove from the list when a context is scheduled in/out (or updated empty<->nonempty). That way we remove chances for erroneous add/remove, and we don't need to treat task and CPU contexts separately in perf_event_task_tick. I managed to get the reproducer running on a box at home, so I'll spin a potential fix against that for a while, and send that out if I don't see explosions. Peter, I guess you'll drop this patch for now? Thanks, Mark.
next prev parent reply other threads:[~2015-01-25 15:57 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-25 4:34 [perf] WARNING: CPU: 0 PID: 1457 at kernel/events/core.c:890 add_event_to_ctx() Fengguang Wu 2015-01-25 4:34 ` Fengguang Wu 2015-01-25 15:56 ` Mark Rutland [this message] 2015-01-25 15:56 ` Mark Rutland 2015-01-26 18:45 ` Mark Rutland 2015-01-26 18:45 ` Mark Rutland 2015-01-28 12:38 ` Peter Zijlstra 2015-01-28 12:38 ` Peter Zijlstra 2015-01-29 13:45 ` Mark Rutland 2015-01-29 13:45 ` Mark Rutland 2015-02-04 14:40 ` [tip:perf/core] perf: Decouple unthrottling and rotating tip-bot for Mark Rutland
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=20150125155633.GA22257@leverpostej \ --to=mark.rutland@arm.com \ --cc=fengguang.wu@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.