linux-kernel - Re: [tip:perf/core] perf: Ignore non-sampling overflows

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: <1309344655.6701.1054.camel@twins>
Date:	Wed, 29 Jun 2011 12:50:55 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Robert Richter <robert.richter@....com>
Cc:	Francis Moreau <francis.moro@...il.com>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [tip:perf/core] perf: Ignore non-sampling overflows

On Wed, 2011-06-29 at 12:37 +0200, Robert Richter wrote:

> I looked at the interrupt handlers. The events are always determined
> from a per-cpu array:
> 
> 	cpuc = &__get_cpu_var(cpu_hw_events);
> 	...
> 	event = cpuc->events[idx];
> 
> In case of interrupts the event should then always be a hw event (or
> uninitialized).  Even if the interrupt was triggered by a different
> source, it would always be mapped to the same event and the check
> is_sampling_event() would be meaningless.

I'm probably not quite getting what you mean, but how is
is_sampling_event() meaningless? the INT bit is enabled for _all_
events, whether they were configured as a sampling event or not.

Its just that for !sampling events we shouldn't attempt to generate any
output.

> There are other occurrences of perf_event_overflow() in
> kernel/events/core.c for events of type PERF_TYPE_SOFTWARE. These
> events are initialized with sample_period set and a check would always
> be true too.

I'm failing to see what you mean, where do we always set
event->attr.sample_period for software events?

> For both cases I stil don't see a reason for the check.

You're going to have to spell things out for me, I'm really not getting
your argument.

> Anyway, would the following extentension of the check above ok?
> 
> 	if (unlikely(!is_sampling_event(event) && !event->attr.sample_type))
> 		...
> 
> With no bits set in attr.sample_type the sample would be empty and
> nothing to report. Now, with this change, samples that have data to
> report wouldn't be dropped anymore.

Also, could you explain in what way data is dropped? Where do
non-sampling events need to write sample data?
--
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/