linux-kernel - Re: [PATCH/RFC 1/2] perfcounters: provide a way to read the current value of interrupting counters

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: <18879.27296.307613.67496@cargo.ozlabs.ibm.com>
Date:	Tue, 17 Mar 2009 20:17:20 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH/RFC 1/2] perfcounters: provide a way to read the
 current value of interrupting counters

Peter Zijlstra writes:

> > It was specifically requested by people porting PAPI to PCL, and it
> > seems like a reasonable request.
> 
> OK, then why didn't the changelog say so :-)

Fair point. :)

> Could you ask them why though, if they need it I won't object too much,
> but I'd like to know the use case.

PAPI has the concept of "overflowing" counters, apparently, which
generate a signal every N counts, about which they said: "One thing to
keep in mind, you should always be able to read a live counter,
regardless of whether or not it's set to overflow..."

I assume the PAPI interface lets you do everything with overflowing
counters that you can do with non-overflowing counters, and that's why
they want it, but I don't know much about PAPI myself.

> As to the method proposed, I think Ingo and I talked about 'abusing'
> non-blocking reads for this purpose, would that work? Then if you need
> two fds you could dup() and flip one to non-blocking.

The non-blocking flag is one of the "file status" flags, which are
shared between all fds pointing at the same struct file.  So if you
dup() and set one to non-blocking, the other one becomes non-blocking
too.  So that doesn't fly.

> The non-blocking read would either output whatever is already pending,
> but in case there is no data, it would generate some on the spot.

The difficulty then is how userspace does know what it ended up
getting?  It may not always be possible to distinguish based on the
value you get.

The other idea I had was to use the file position, and say that
positions greater than some threshold read the event queue, and less
than the threshold read the counter value.  That way you can read the
event queue with read() and the counter value with pread(..., 0).

The objection to that is that the threshold is a bit artificial, and
would need to be different between interrupting and counting
counters.  Also we may need to do strange things to file->f_pos like
initializing it to the (non-zero) threshold when opening an
interrupting counter.

Paul.
--
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/