From: Peter Zijlstra <peterz@infradead.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>, Paul Mackerras <paulus@samba.org>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH,RFC] perf: panic due to inclied cpu context task_ctx value
Date: Tue, 29 Mar 2011 12:49:49 +0200 [thread overview]
Message-ID: <1301395789.2250.376.camel@laptop> (raw)
In-Reply-To: <1301387532.4859.54.camel@twins>
On Tue, 2011-03-29 at 10:32 +0200, Peter Zijlstra wrote:
> @@ -2922,15 +2926,40 @@ static void free_event(struct perf_event
> call_rcu(&event->rcu_head, free_event_rcu);
> }
>
> -int perf_event_release_kernel(struct perf_event *event)
> +static int __perf_event_release(void *info)
> {
> + struct perf_event *event = info;
> struct perf_event_context *ctx = event->ctx;
> + struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
> + int ret;
>
> /*
> - * Remove from the PMU, can't get re-enabled since we got
> - * here because the last ref went.
> + * Disable the event if its still running, we're shutting down.
> */
> - perf_event_disable(event);
> + ret = __perf_event_disable(info);
> + if (ret)
> + return ret;
> +
> + raw_spin_lock_irq(&ctx->lock);
> + perf_group_detach(event);
> + list_del_event(event, ctx);
> + /*
> + * In case we removed the last event from an active task_ctx
> + * deactivate the task_ctx because this event being freed might
> + * lead to the perf_sched_events jump_label being disabled
> + * which avoids the task sched-out hook from being called.
> + */
> + if (!ctx->nr_events && cpuctx->task_ctx == ctx) {
> + ctx->is_active = 0;
> + cpuctx->task_ctx = NULL;
> + }
> + raw_spin_unlock_irq(&ctx->lock);
> +}
> +
> +int perf_event_release_kernel(struct perf_event *event)
> +{
> + struct perf_event_context *ctx = event->ctx;
> + struct task_struct *task = ctx->task;
>
> WARN_ON_ONCE(ctx->parent_ctx);
> /*
> @@ -2946,10 +2975,28 @@ int perf_event_release_kernel(struct per
> * to trigger the AB-BA case.
> */
> mutex_lock_nested(&ctx->mutex, SINGLE_DEPTH_NESTING);
> + if (!task) {
> + cpu_function_call(event->cpu, __perf_event_release, event);
> + goto unlock;
> + }
> +
> +retry:
> + if (!task_function_call(task, __perf_event_release, event))
> + goto unlock;
> +
> raw_spin_lock_irq(&ctx->lock);
> + if (ctx->is_active) {
> + raw_spin_unlock_irq(&ctx->lock);
> + goto retry;
> + }
> +
> + WARN_ON_ONCE(event->state == PERF_EVENT_STATE_ACTIVE);
> +
> perf_group_detach(event);
> list_del_event(event, ctx);
> raw_spin_unlock_irq(&ctx->lock);
> +
> +unlock:
> mutex_unlock(&ctx->mutex);
>
> free_event(event);
we can simplify that and use perf_remove_from_context(), except that
changes the close() semantics slightly for grouped events, the current
code will I think deschedule the complete group when you close the
leader, when using pref_remote_from_context() we'll promote the siblings
to individual events and let them run when you close the leader.
I'm fairly sure no-one _should_ rely on that, but they _might_..
next prev parent reply other threads:[~2011-03-29 10:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 16:44 [PATCH,RFC] perf: panic due to inclied cpu context task_ctx value Jiri Olsa
2011-03-25 19:10 ` Oleg Nesterov
2011-03-26 15:37 ` Peter Zijlstra
2011-03-26 16:13 ` Oleg Nesterov
2011-03-26 16:38 ` Peter Zijlstra
2011-03-26 17:09 ` Oleg Nesterov
2011-03-26 17:35 ` Oleg Nesterov
2011-03-26 18:29 ` Peter Zijlstra
2011-03-26 18:49 ` Oleg Nesterov
2011-03-28 13:30 ` Oleg Nesterov
2011-03-28 14:57 ` Peter Zijlstra
2011-03-28 15:00 ` Peter Zijlstra
2011-03-28 15:15 ` Oleg Nesterov
2011-03-28 16:27 ` Peter Zijlstra
2011-03-28 15:39 ` Oleg Nesterov
2011-03-28 15:49 ` Peter Zijlstra
2011-03-28 16:56 ` Oleg Nesterov
2011-03-29 8:32 ` Peter Zijlstra
2011-03-29 10:49 ` Peter Zijlstra [this message]
2011-03-29 16:28 ` Oleg Nesterov
2011-03-29 19:01 ` Peter Zijlstra
2011-03-30 13:09 ` Jiri Olsa
2011-03-30 14:51 ` Peter Zijlstra
2011-03-30 16:37 ` Oleg Nesterov
2011-03-30 18:30 ` Paul E. McKenney
2011-03-30 19:53 ` Oleg Nesterov
2011-03-30 21:26 ` Peter Zijlstra
2011-03-30 21:35 ` Oleg Nesterov
2011-03-31 10:32 ` Jiri Olsa
2011-03-31 12:41 ` [tip:perf/urgent] perf: Fix task context scheduling tip-bot for Peter Zijlstra
2011-03-31 13:28 ` [PATCH,RFC] perf: panic due to inclied cpu context task_ctx value Oleg Nesterov
2011-03-31 13:51 ` Peter Zijlstra
2011-03-31 14:10 ` Oleg Nesterov
2011-04-04 16:20 ` Oleg Nesterov
2011-03-30 15:32 ` Oleg Nesterov
2011-03-30 15:40 ` Peter Zijlstra
2011-03-30 15:52 ` Oleg Nesterov
2011-03-30 15:57 ` Peter Zijlstra
2011-03-30 16:11 ` Peter Zijlstra
2011-03-30 17:13 ` Oleg Nesterov
2011-03-26 17:09 ` Peter Zijlstra
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=1301395789.2250.376.camel@laptop \
--to=peterz@infradead.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=paulus@samba.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