public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.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: Sun, 28 Jun 2009 14:35:31 -0700	[thread overview]
Message-ID: <m163egt524.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090628135235.10f9b153.akpm@linux-foundation.org> (Andrew Morton's message of "Sun\, 28 Jun 2009 13\:52\:35 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:

> On Sun, 28 Jun 2009 21:31:12 +0200 Andi Kleen <andi@firstfloor.org> wrote:
>
>> > One way would be to add a new sysctl-externs.h and then put all the
>> > declarations in there.  That file gets included by sysctl.c and by each
>> > file which shares a global with sysctl.c
>> 
>> Long ago I had a experimental patch to put sysctls into a new ELF section. The 
>> you could simply put a DEFINE_SYSCTL(....) into the appropiate source file
>> which defined the variable and most of the tables went.
>> 
>> No externs, no mess, no patch collisions, everything much nicer.
>> 
>> The only problem was that it didn't support the numerical sysctl
>> space, so that would need to be removed first.
>> 
>> It's deprecated for quite some time now:
>> 
>>   if (msg_count < 5) {
>>                 msg_count++;
>>                 printk(KERN_INFO
>>                         "warning: process `%s' used the deprecated sysctl "
>>                         "system call with ", current->comm);
>> 
>> Should it finally go now? If yes I could polish up the old patch again.
>> 
>
> I suspect that it will be a long time before we can actually remove the
> numerical sysctl support, if ever.  In _theory_ we should support it
> for ever.  But in practice, we could probably remove it with a minimum
> of disruption a few years hence, but it's hard to work this out.
>
> When was the last time we saw a "warning: process `%s' used the
> obsolete bdflush system call" warning?  A quick google here says 2004. 
> Is that data?  A bit, I guess.
>
> Maybe Eric has thought about this issue?

I have a patchset.  That I intend to dust off now and repost now that the
merge window has closed that converts all of the binary sysctl handling
into compatibility code that calls read/write on the ascii sysctls.

The bulk of the patchset is removing all of the binary sysctl support code
from all of the susbystems that it makes no longer needed.

At which point the maintenance pain is of all of the binary sysctls is
essentially removed.

At which point the technical decisions on dumping binary become much
easier.  They are reduced to one big file that we can keep or compile
out at our leisure.  I still figure September 2010 as documented in
feature-removal.txt sounds like a good date for the final ripping all of
the binary sysctl code out.

It is certainly time to remove the internal ABIs.  The current system
is still too error prone, for users adding new sysctls.  It was only
a week or two ago that I had to nack a patch for adding a binary sysctl.

Once we have purged the binary parts it should be much easier to simplify
the sysctl code.

So my big question:

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?

Eric


  parent reply	other threads:[~2009-06-28 21:35 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 [this message]
2009-06-28 21:48             ` Andi Kleen
2009-06-28 22:06               ` Eric W. Biederman
2009-06-29  9:15                 ` Andi Kleen
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=m163egt524.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=earl_chew@agilent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox