[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o8vfbtq0.fsf@ashishki-desk.ger.corp.intel.com>
Date: Tue, 07 Jan 2020 09:39:51 +0200
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Mark Rutland <mark.rutland@....com>,
Vince Weaver <vincent.weaver@...ne.edu>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
alexander.shishkin@...ux.intel.com
Subject: Re: [PATCH] perf: correctly handle failed perf_get_aux_event() (was: Re: [perf] perf_event_open() sometimes returning 0)
Mark Rutland <mark.rutland@....com> writes:
> On Thu, Jan 02, 2020 at 02:22:47PM -0500, Vince Weaver wrote:
>> On Thu, 2 Jan 2020, Vince Weaver wrote:
>>
>> > so I was tracking down some odd behavior in the perf_fuzzer which turns
>> > out to be because perf_even_open() sometimes returns 0 (indicating a file
>> > descriptor of 0) even though as far as I can tell stdin is still open.
>
> Yikes.
>
>> error is triggered if aux_sample_size has non-zero value.
>>
>> seems to be this line in kernel/events/core.c:
>>
>>
>> if (perf_need_aux_event(event) && !perf_get_aux_event(event, group_leader))
>> goto err_locked;
>>
>>
>> (note, err is never set)
>
> Looks like that was introduced in commit:
>
> ab43762ef010967e ("perf: Allow normal events to output AUX data")
>
> I guess we should return -EINVAL in this case.
That's right. Thanks for looking into this!
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index a1f8bde19b56..2173c23c25b4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -11465,8 +11465,10 @@ SYSCALL_DEFINE5(perf_event_open,
> }
> }
>
> - if (perf_need_aux_event(event) && !perf_get_aux_event(event, group_leader))
> + if (perf_need_aux_event(event) && !perf_get_aux_event(event, group_leader)) {
> + err = -EINVAL;
> goto err_locked;
> + }
>
FWIW,
Acked-by: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Thanks,
--
Alex
Powered by blists - more mailing lists