Re: [RFC][PATCH] perf_counter: Complete counter swap.

[Paul Mackerras]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/