[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140106163950.GP31570@twins.programming.kicks-ass.net>
Date: Mon, 6 Jan 2014 17:39:50 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Yann Droneaud <ydroneaud@...eya.com>,
Paul Mackerras <paulus@...ba.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Stephane Eranian <eranian@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Michael Ellerman <michael@...erman.id.au>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf tools: enable close-on-exec flag on perf file
descriptor
On Mon, Jan 06, 2014 at 08:27:54AM -0800, Andi Kleen wrote:
> On Mon, Jan 06, 2014 at 11:51:25AM +0100, Yann Droneaud wrote:
> > In a previous patch [1][2], flag PERF_FLAG_FD_CLOEXEC was
> > added to perf_event_open(2) syscall to allows userspace
> > to enable close-on-exec behavor atomically when creating
> > the file descriptor.
> >
> > This patch makes perf tools use the new flag.
>
> What is that good for? I can see why for a threaded program, but
> "perf" is not threaded.
AFAICT its got nothing to do with threaded or not, but only with exec()
and we do in fact call exec() quite a lot in perf.
It ensures we do not leak open perf FDs into our child processes. Now
I'm not entirely sure how we do the exec these days but I think we were
good about not not leaking them anyway, but more paranoia never really
hurts.
--
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