linux-kernel - Re: [PATCH] perf_events: fix errors path in perf_output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTil2QBjH2qvnH7VKrg6s7RcKvHC1m0HZkDVDPzv5@mail.gmail.com>
Date:	Mon, 17 May 2010 13:56:38 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu,
	paulus@...ba.org, davem@...emloft.net, acme@...radead.org,
	perfmon2-devel@...ts.sf.net, eranian@...il.com
Subject: Re: [PATCH] perf_events: fix errors path in perf_output_begin()

On Mon, May 17, 2010 at 1:46 PM, Frederic Weisbecker <fweisbec@...il.com> wrote:
> On Mon, May 17, 2010 at 12:46:01PM +0200, Stephane Eranian wrote:
>>   In case the sampling buffer has no "payload" pages, nr_pages is 0.
>>   The problem is that the error path in perf_output_begin() skips to
>>   a label which assumes perf_output_lock() has been issued which is
>>   not the case. That triggers a WARN_ON() is perf_output_unlock().
>>
>>   This patch fixes the problem by adding a new label and skipping
>>   perf_task_unlock() in case data->nr_pages is 0.
>>
>>   Signed-off-by: Stephane Eranian <eranian@...gle.com>
>>
>> --
>> diff --git a/kernel/perf_event.c b/kernel/perf_event.c
>> index a4fa381..95137b6 100644
>> --- a/kernel/perf_event.c
>> +++ b/kernel/perf_event.c
>> @@ -3035,8 +3035,10 @@ int perf_output_begin(struct perf_output_handle *handle,
>>       handle->nmi     = nmi;
>>       handle->sample  = sample;
>>
>> -     if (!data->nr_pages)
>> -             goto fail;
>> +     if (!data->nr_pages) {
>> +             atomic_inc(&data->lost);
>> +             goto out;
>> +     }
>
>
>
> Oh indeed, handle->lock is in a random state.
> Whatever its value we have an unbalanced put_cpu()
> anyway.
>
Yes, I caught this problem while debugging the perf record -c
issue.

> And we don't race with someone else, data->lock = -1
> and will then warn.
>
> I just have a tiny doubt: should we really count this
> path to the lost events? I'm not sure when we can have
> data->nr_pages == 0, does this happen if we mmap after
> enabling the event?
>
Well, nr_pages = 0 means all you have is the sampling buffer
header page. You cannot save any sample, so you  actually
loose everything. Perf reports a dozen samples but those
are synthetic. The kernel cannot reject an mmap() for
just one page because of the remapped counters, thus it
has to handle this gracefully and at least report the lost
samples.

> All I know is that I observed I already lost events in
> this path using perf lock.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/