[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314283065.27911.23.camel@twins>
Date: Thu, 25 Aug 2011 16:37:45 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Vince Weaver <vweaver1@...s.utk.edu>
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
acme@...stprotocols.net, Stephane Eranian <eranian@...il.com>,
krentel@...rice.edu
Subject: Re: perf: overflow signal survives an exec call starting in 3.0
On Tue, 2011-08-23 at 11:36 -0400, Vince Weaver wrote:
> I'm guessing this was an unintended change, although what to do in
> this situation is a bit vague.
>
> commit f506b3dc0ec454a16d40cab9ee5d75435b39dc50
> Author: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Date: Thu May 26 17:02:53 2011 +0200
>
> perf: Fix SIGIO handling
Ah, quite... its a combination of way too many weird things.
So that change made it possible (as requested) to receive a signal
without having to mmap() the buffer, which seems like a perfectly sane
thing.
Now, looking at fs/exec.c:setup_new_exec() we see that we only call
perf_event_exit_task() when we cross a security domain.
Previously the exec() would have wiped out the mmap, and hence the
counter would have stopped sending signals (but not stopped counting).
Now exec() doesn't normally close fds, so the counter stays around and
with the new scheme continues sending signals.
I think the message is, don't do that then.. and use fcntl(fd, F_SETFD,
FD_CLOEXEC) or so.
--
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/
Powered by blists - more mailing lists