linux-kernel - Re: perf: [patch] regression with PERF_EVENT_IOC

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: <Pine.LNX.4.64.1105310942410.9995@pianoman.cluster.toy>
Date:	Tue, 31 May 2011 09:49:52 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Vince Weaver <vweaver1@...s.utk.edu>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, paulus@...ba.org, acme@...hat.com
Subject: Re: perf: [patch] regression with PERF_EVENT_IOC_REFRESH

On Tue, 31 May 2011, Peter Zijlstra wrote:

> On Mon, 2011-05-30 at 21:33 -0400, Vince Weaver wrote:
> > the problem was the mentioned commit tried to optimize the use of 
> > watermark and wakeup_watermark without taking into account that 
> > wakeup_watermark is a union with wakeup_events. 
> 
> Note that wake_events isn't related to IOC_REFRESH, wake_events is how
> much events to buffer in the mmap-buffer before issuing a wakeup.
> 
> IOC_REFRESH increments event_limit, which is how many events to run
> before disabling yourself.
> 
> What I gather is that due to that SIGIO bug (fixed by f506b3dc0e), you
> had to have both an mmap and a wakeup in order for that signal to
> arrive.

yes, but due to a bug in the mentioned changeset, the buffer watermark 
value was being set to a low value even if *watermark* was 0.  So if you 
were using IOC_REFRESH to set the *wakeup_events* value, it was also 
setting the *wakeup_watermark* value (it's a union) and the buffer setup 
was then unconditionally setting the buffer watermark to the value of the 
supposedly unrelated *wakeup_watermark*.  Normally the wakeup watermark 
would default to something like 2048, but if you were trying to set the 
wakeup_events value to something like 3 then wakeup_watermark would be set 
to that too, causing a lot more overflow events.

I verified all the above painfully using a lot of printks.

I agree this does seem to be a combination of bugs, as even with a 
properlyu set value on affected kernels you'd get spurious watermark 
overflow events if you weren't consuming the ring buffer.

In any case, I can provide a cleaner patch than the one before that isn't 
as intrusive.

I'm also bisecting the other problem I mentioned, the one where overflows 
are 10x too large on 3.0-rc1.  I'm at work with a Nehalem machine so the 
bisect should go faster than the bisect I had to do on an atom machine 
this weekend.  

A power outage over the weekend has taken part of the 
network down here though so my e-mail access is a bit limited, so I 
apologize if I've been missing comments sent to my other e-mail address.

Vince
--
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/