linux-kernel - Re: [RFC][PATCH] perf_counter: Complete counter swap.

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: <19012.49854.67117.211218@cargo.ozlabs.ibm.com>
Date:	Fri, 26 Jun 2009 22:44:46 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [RFC][PATCH] perf_counter: Complete counter swap.

Peter Zijlstra writes:

> Right, so I convinced myself we indeed want to swap the times as well,
> and realized we need to update the userpage after modifying these
> counters.
> 
> Then again, since inherited counters tend to wander around
> self-monitoring mmap() + inherit is bound to be broken.. hmm?
> 
> Do we want to fix that or shall we simply say: don't do that then!

We only swap the contexts around if all the counters in both contexts
have been inherited, i.e. neither context is a top-level parent
context.  Now I had been going to say that a counter that had been
inherited couldn't be used for self-monitoring, and I think that is
actually true, but I guess the problem is that the child could have
inherited the fd and the mmap too, but the mmap will be on the parent
counter not the inherited child counter.  And there's no way for the
child (or anyone) to mmap the inherited counter since there's no fd
for it.

Currently we don't do anything to stop people trying to read the
counters directly when they're not self-monitoring - they just get
bogus data.  Maybe we should put the tid of the task the counter's on
into the first page of the mmap so that userspace can at least check
if it's the task being monitored.

Unless you can see some way to change the mmap on fork to point to the
child counter rather than the parent...  Which would possibly be a bit
nasty anyway since then the child's address space wouldn't be clone of
the parent's like you would expect after a fork.

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/