All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: alexander.shishkin@linux.intel.com, ak@linux.intel.com,
	kan.liang@linux.intel.com, nadav.amit@gmail.com,
	Zhengjun Xing <zhengjun.xing@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	jolsa@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	mingo@redhat.com, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH] perf/core: Fix the same task check in perf_event_set_output
Date: Wed, 22 Mar 2023 14:42:03 +0100	[thread overview]
Message-ID: <20230322134203.GB2357380@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <be7e6a74-4863-d5eb-51ff-26aa2890f2bd@intel.com>

On Wed, Mar 22, 2023 at 12:59:28PM +0200, Adrian Hunter wrote:
> On 11/07/22 21:07, kan.liang@linux.intel.com wrote:
> > From: Kan Liang <kan.liang@linux.intel.com>
> > 
> > With the --per-thread option, perf record errors out when sampling with
> > a hardware event and a software event as below.
> > 
> >  $ perf record -e cycles,dummy --per-thread ls
> >  failed to mmap with 22 (Invalid argument)
> > 
> > The same task is sampled with the two events. The IOC_OUTPUT is invoked
> > to share the mmap memory of the task between the events. In the
> > perf_event_set_output(), the event->ctx is used to check whether the
> > two events are attached to the same task. However, a hardware event and
> > a software event are from different task context. The check always
> > fails.
> > 
> > The task struct is stored in the event->hw.target for each per-thread
> > event. It can be used to determine whether two events are attached to
> > the same task.
> > 
> > The patch can also fix another issue reported months ago.
> > https://lore.kernel.org/all/92645262-D319-4068-9C44-2409EF44888E@gmail.com/
> > The event->ctx is not ready when the perf_event_set_output() is invoked
> > in the perf_event_open(), while the event->hw.target has been assigned
> > at the moment.
> > 
> > The problem should be a long time issue since commit c3f00c70276d
> > ("perf: Separate find_get_context() from event initialization"). The
> > event->hw.target doesn't exist at that time. Here, the patch which
> > introduces the event->hw.target is used by the Fixes tag.
> > 
> > The problem should still exists between the broken patch and the
> > event->hw.target patch. This patch does not intend to fix that case.
> > 
> > Fixes: 50f16a8bf9d7 ("perf: Remove type specific target pointers")
> > Reviewed-by: Zhengjun Xing <zhengjun.xing@linux.intel.com>
> > Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> 
> Did this slip through the cracks, or is there more complexity
> to this case than just sharing the rb?

Both; I very much missed it, but looking at it now, I'm not at all sure
it is correct prior to the whole context rewrite we did recently.

So after the rewrite every cpu/task only has a single
perf_event_context, and your change below is actually an equivalence.

But prior to that a task could have multiple contexts. Now they got
co-scheduled most of the times and it will probably work, but I'm not
entirely sure.

So how about we change the Fixes tag to something like:

Fixes: c3f00c70276d ("perf: Separate find_get_context() from event initialization") # >= v6.2

And anybody that wants to back-port this further gets to either do the
full audit and/or keep the pieces.

Hmm?

> > ---
> >  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 b4d62210c3e5..22df79d3f19d 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -12080,7 +12080,7 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event)
> >  	/*
> >  	 * If its not a per-cpu rb, it must be the same task.
> >  	 */
> > -	if (output_event->cpu == -1 && output_event->ctx != event->ctx)
> > +	if (output_event->cpu == -1 && output_event->hw.target != event->hw.target)
> >  		goto out;
> >  
> >  	/*
> 

  reply	other threads:[~2023-03-22 13:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 18:07 [PATCH] perf/core: Fix the same task check in perf_event_set_output kan.liang
2023-03-22 10:59 ` Adrian Hunter
2023-03-22 13:42   ` Peter Zijlstra [this message]
2023-03-22 14:15     ` Adrian Hunter
2023-03-22 19:17       ` Liang, Kan

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=20230322134203.GB2357380@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=namhyung@kernel.org \
    --cc=zhengjun.xing@linux.intel.com \
    /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 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.