From: Andi Kleen <andi@firstfloor.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Neil Horman <nhorman@tuxdriver.com>,
linux-kernel@vger.kernel.org, earl_chew@agilent.com,
Oleg Nesterov <oleg@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern
Date: Mon, 29 Jun 2009 11:15:29 +0200 [thread overview]
Message-ID: <20090629091529.GD6760@one.firstfloor.org> (raw)
In-Reply-To: <m1hby0qahq.fsf@fess.ebiederm.org>
On Sun, Jun 28, 2009 at 03:06:25PM -0700, Eric W. Biederman wrote:
> Andi Kleen <andi@firstfloor.org> writes:
>
> >> Andrew should I toss all 100 or so patches over the wall to you
> >> and your -mm tree? Or should I maintain a public git tree based
> >> at 2.6.31-rc1? Get it into linux-next and ask Linus to pull it when
> >> the merge window comes?
> >
> > What do these 100 odd patches do exactly?
>
> Mostly a fine grained killing of ctl_name, and strategy.
Ok.
The only issue is -- assuming we convert that over to DEFINE_SYSCTL
too (which I think would be much nicer) all tee maintainers would
need to process two patches. So perhaps it would be better to combine
this into a single update?
> > Then the binary sysctls could be handled by a global table
> > in a separate file like you described
>
> Getting the binary sysctl crud out of the core path should
> happen first. That is just a handful of patches.
Agreed. It should be just a separate table.
> > the current interfaces are not great, but could be probably kept.
>
> Things like register_sysctl_path can be greatly improved. Now
> that we don't have to worry about the binary paths.
With a module DEFINE_SYSCTL() only truly dynamic sysctls (like
the network per device sysctls) would need that anyways; the
far majority of callers wouldn't need to call any functions.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2009-06-29 9:15 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 17:28 [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern Neil Horman
2009-06-25 23:30 ` Andrew Morton
2009-06-26 1:49 ` Neil Horman
2009-06-26 10:48 ` Neil Horman
2009-06-26 16:20 ` Andrew Morton
2009-06-26 17:30 ` Neil Horman
2009-06-28 19:31 ` Andi Kleen
2009-06-28 20:52 ` Andrew Morton
2009-06-28 21:00 ` Andi Kleen
2009-06-28 21:18 ` Andrew Morton
2009-06-28 21:50 ` Eric W. Biederman
2009-06-28 21:35 ` Eric W. Biederman
2009-06-28 21:48 ` Andi Kleen
2009-06-28 22:06 ` Eric W. Biederman
2009-06-29 9:15 ` Andi Kleen [this message]
2009-06-28 21:52 ` Andrew Morton
2009-06-26 18:00 ` Neil Horman
2009-06-26 18:02 ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: recursive dump detection Neil Horman
2009-06-26 16:59 ` Oleg Nesterov
2009-06-26 20:24 ` Neil Horman
2009-06-26 19:14 ` [PATCH 0/2] do_coredump: misc cleanups Oleg Nesterov
2009-06-26 19:14 ` [PATCH 1/2] do_coredump: factor out put_cred() calls Oleg Nesterov
2009-06-26 22:40 ` Roland McGrath
2009-06-26 20:33 ` Oleg Nesterov
2009-06-26 19:16 ` [PATCH 2/2] do_coredump: move !ispipe code into "else" branch Oleg Nesterov
2009-06-26 20:18 ` Q: do_coredump() && d_unhashed() Oleg Nesterov
2009-06-26 22:57 ` [PATCH 0/2] do_coredump: misc cleanups Neil Horman
2009-06-26 19:37 ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: recursive dump detection Andrew Morton
2009-06-26 20:17 ` Neil Horman
2009-06-26 18:03 ` [PATCH 2/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: wait for core collectors Neil Horman
2009-06-26 16:48 ` Oleg Nesterov
2009-06-26 20:20 ` Neil Horman
2009-06-29 0:33 ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v3) Neil Horman
2009-06-29 0:35 ` [PATCH 2/2] " Neil Horman
2009-06-28 22:24 ` Oleg Nesterov
2009-06-28 23:24 ` Oleg Nesterov
2009-06-29 2:36 ` Neil Horman
2009-06-28 23:32 ` Oleg Nesterov
2009-06-29 10:21 ` Neil Horman
2009-06-30 0:06 ` Oleg Nesterov
2009-06-29 0:32 ` [PATCH 0/2] " Neil Horman
2009-06-30 17:38 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v4) Neil Horman
2009-06-30 17:42 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v4) Neil Horman
2009-06-30 17:43 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v4) Neil Horman
2009-06-30 17:46 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v4) Neil Horman
2009-07-01 5:52 ` Oleg Nesterov
2009-07-01 10:31 ` Neil Horman
2009-07-01 12:25 ` Oleg Nesterov
2009-07-01 14:12 ` Neil Horman
2009-07-01 14:48 ` Oleg Nesterov
2009-07-01 15:26 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v5) Neil Horman
2009-07-01 15:30 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v5) Neil Horman
2009-07-01 15:34 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v5) Neil Horman
2009-07-01 15:37 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v5) Neil Horman
2009-07-01 16:06 ` Oleg Nesterov
2009-07-01 18:19 ` Neil Horman
2009-07-01 18:28 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v6) Neil Horman
2009-07-01 18:31 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v6) Neil Horman
2009-07-01 18:32 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v6) Neil Horman
2009-07-01 18:37 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v6) Neil Horman
2009-07-02 8:29 ` Oleg Nesterov
2009-07-02 10:29 ` Neil Horman
2009-07-02 11:36 ` Oleg Nesterov
2009-07-02 14:44 ` Neil Horman
2009-07-02 15:37 ` Oleg Nesterov
2009-07-02 17:53 ` Neil Horman
2009-07-03 10:10 ` Oleg Nesterov
2009-07-02 22:57 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v7) Neil Horman
2009-07-02 22:59 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v7) Neil Horman
2009-07-02 23:00 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v7) Neil Horman
2009-07-02 23:01 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v7) Neil Horman
2009-07-03 10:16 ` Oleg Nesterov
2009-07-03 10:44 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v8) Neil Horman
2009-07-03 10:50 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v8) Neil Horman
2009-07-07 16:14 ` Neil Horman
2009-07-03 10:51 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v8) Neil Horman
2009-07-07 16:15 ` Neil Horman
2009-07-03 10:52 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v8) Neil Horman
2009-07-07 16:19 ` Neil Horman
2009-07-07 16:35 ` Oleg Nesterov
2009-07-07 16:13 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v8) Neil Horman
2009-07-20 15:49 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v9) Neil Horman
2009-07-20 16:27 ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v9) Neil Horman
2009-07-20 16:29 ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v9) Neil Horman
2009-08-07 17:08 ` Randy Dunlap
2009-07-20 16:32 ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v9) Neil Horman
2009-07-29 15:13 ` [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern Scott James Remnant
2009-07-29 20:18 ` Neil Horman
2009-07-31 20:20 ` Scott James Remnant
2009-08-01 13:41 ` Neil Horman
2009-08-01 18:28 ` Scott James Remnant
2009-08-02 0:22 ` Neil Horman
2009-08-02 13:49 ` Scott James Remnant
2009-08-02 23:50 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090629091529.GD6760@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=earl_chew@agilent.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.