LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@redhat.com>,
	Alexey Budankov <alexey.budankov@linux.intel.com>,
	tglx@linutronix.de, Dmitry.Prohorov@intel.com,
	alexander.shishkin@linux.intel.com, acme@redhat.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	torvalds@linux-foundation.org, mingo@kernel.org,
	vincent.weaver@maine.edu, kan.liang@intel.com,
	eranian@google.com, davidcc@google.com,
	valery.cherepennikov@intel.com,
	linux-tip-commits@vger.kernel.org
Subject: [PATCH] perf/core: clear sibling list of detached events (was "Re: [PATCH] perf: Fix sibling iteration")
Date: Fri, 16 Mar 2018 13:17:41 +0000
Message-ID: <20180316131741.3svgr64yibc6vsid@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20180316105017.GD4064@hirez.programming.kicks-ass.net>

On Fri, Mar 16, 2018 at 11:50:17AM +0100, Peter Zijlstra wrote:
> On Fri, Mar 16, 2018 at 11:39:46AM +0100, Jiri Olsa wrote:
> > On Fri, Mar 16, 2018 at 11:31:29AM +0100, Peter Zijlstra wrote:

> > > There is at least one more known issue with that patch, but neither Mark
> > > nor me could reproduce so far, so we don't know if we're right about the
> > > cause.
> > 
> > is there more info about that issue? I could try it
> 
> Find below, 0day report didn't go out to lkml. We think moving the
> list_del_init() out from the !RB_NODE_EMPTY() test might fix, but since
> we can't repro so far, its all guesses.

In testing, I can see this always fires after we perf_group_detach() a
leader whose group_node is empty.

With the list_del_init() pulled out of that check, I see that we still
hit the leaders with an empty group_node (with a hacked-in WARN_ON), but
no longer blow up in a subsequent perf_group_detach().

I've given this 50 boots with the 0day scripts, and no explosions so far
(with 5 boots where a leader had an empty group_node).

Thanks,
Mark.

---->8----
>From 136ebe0f3756d4cf1a37f6d00b7ec1b902980b83 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Fri, 16 Mar 2018 12:51:40 +0000
Subject: [PATCH] perf/core: clear sibling list of detached events

When perf_group_dettach() is called on a group leader, it updates each
sibling's group_leader field to point to that sibling, effectively
upgrading each siblnig to a group leader. After perf_group_detach has
completed, the caller may free the leader event.

We only remove siblings from the group leader's sibling_list when the
leader has a non-empty group_node. This was fine prior to commit:

  8343aae66167df67 ("perf/core: Remove perf_event::group_entry")

... as the sibling's sibling_list would be empty. However, now that we
use the sibling_list field as both the list head and the list entry,
this leaves each sibling with a non-empty sibling list, including the
stale leader event.

If perf_group_detach() is subsequently called on a sibling, it will
appear to be a group leader, and we'll walk the sibling_list,
potentially dereferencing these stale events. In 0day testing, this has
been observed to result in kernel panics.

Let's avoid this by always removing siblings from the sibling list when
we promote them to leaders.

Fixes: 8343aae66167df67 ("perf/core: Remove perf_event::group_entry")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9a07bbe66451..627814e1820d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1917,12 +1917,12 @@ static void perf_group_detach(struct perf_event *event)
 	list_for_each_entry_safe(sibling, tmp, &event->sibling_list, sibling_list) {
 
 		sibling->group_leader = sibling;
+		list_del_init(&sibling->sibling_list);
 
 		/* Inherit group flags from the previous leader */
 		sibling->group_caps = event->group_caps;
 
 		if (!RB_EMPTY_NODE(&event->group_node)) {
-			list_del_init(&sibling->sibling_list);
 			add_event_to_groups(sibling, event->ctx);
 		}
 
-- 
2.11.0

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tip-8343aae66167df6708128a778e750d48dbe31302@git.kernel.org>
2018-03-15 17:01 ` [PATCH] perf: Fix sibling iteration Peter Zijlstra
2018-03-16  9:59   ` Alexey Budankov
2018-03-16 10:31     ` Peter Zijlstra
2018-03-16 10:39       ` Jiri Olsa
2018-03-16 10:50         ` Peter Zijlstra
2018-03-16 12:07           ` Mark Rutland
2018-03-16 13:17           ` Mark Rutland [this message]
2018-03-16 13:44             ` [PATCH] perf/core: clear sibling list of detached events (was "Re: [PATCH] perf: Fix sibling iteration") Peter Zijlstra
2018-03-16 14:37             ` [tip:perf/core] perf/core: Clear sibling list of detached events tip-bot for Mark Rutland
2018-03-16 19:49             ` tip-bot for Mark Rutland
2018-03-16 10:53       ` [PATCH] perf: Fix sibling iteration Alexey Budankov
2018-03-16 14:36   ` [tip:perf/core] " tip-bot for Peter Zijlstra
2018-03-16 19:49   ` tip-bot for 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=20180316131741.3svgr64yibc6vsid@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=Dmitry.Prohorov@intel.com \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=davidcc@google.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=valery.cherepennikov@intel.com \
    --cc=vincent.weaver@maine.edu \
    /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

	# 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 \
		linux-kernel@vger.kernel.org
	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