[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1389028547.13828.20.camel@localhost.localdomain>
Date: Mon, 06 Jan 2014 18:15:47 +0100
From: Yann Droneaud <ydroneaud@...eya.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
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, Yann Droneaud <ydroneaud@...eya.com>
Subject: Re: [PATCH] perf tools: enable close-on-exec flag on perf file
descriptor
Hi,
Le lundi 06 janvier 2014 à 08:52 -0800, Andi Kleen a écrit :
> > 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.
>
> Then you can just set it with fcntl, which works everywhere,
> instead of doing extra feature tests.
>
> The atomic setup is only needed for threaded programs to avoid
> races with other threads doing exec.
>
True.
The purpose of this patch was more about exercising the new flag
proposed for perf_event_open() as a way to demonstrate its usage.
Having it used in the perf code base will likely help to spread it to
other tools based on perf event API.
Trying to add a close-on-exec enable flag late emphasis it should have
been done earlier and perhaps made the default.
As I wrote in "[PATCH v5 0/7] Getting rid of get_unused_fd() / enable
close-on-exec" [1], setting close-on-exec at open time is easier to
write for the programmer and less error prone than trying to add call to
fcntl() and forget to add it in some code path. (forgetting to add the
proper flag to open() is probably more error prone ... so one might want
to make close-on-exec the *default* for any new API).
[1] http://lkml.kernel.org/r/cover.1388952061.git.ydroneaud@opteya.com
Regards.
--
Yann Droneaud
OPTEYA
--
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