public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cong Wang <amwang@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@xenotime.net>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Len Brown <len.brown@intel.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	Eric Paris <eparis@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andy Shevchenko <ext-andriy.shevchenko@nokia.com>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/2] sysctl: remove sysctl syscall
Date: Wed, 20 Oct 2010 06:54:15 -0700	[thread overview]
Message-ID: <m1zku99dh4.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4CBE86E0.3050505@redhat.com> (Cong Wang's message of "Wed, 20 Oct 2010 14:06:24 +0800")

Cong Wang <amwang@redhat.com> writes:

> On 10/20/10 00:00, Eric W. Biederman wrote:
>> To the best of my knowledge the last and user of sys_sysctl is the glibc
>> ioperm (my apologies I mispoke when I said iopl) implementation on arm.
>> Not that people run around calling ioperm very often in any distro.
>
>
> I saw that in Changelog of glibc too, but that was back to 2000, 10 years
> past, I don't see any code using sysctl() in glibc now, except sys_sysctl()
> itself, of course.

You have to look in the glibc-ports tree to see the arm code.

The arm support is not in the main glibc tree for some reason.

Hmm. Looking I thought sys_sysctl had stopped being exported from glibc
but it appears I was wrong.

>> All of that said I think disabling sys_sysctl by default now is totally
>> reasonable.  If there is a percentage in removing the code we can worry
>> about that later.  Perhaps we should add a CONFIG_CRUFT and move
>> sys_sysctl under there.  Binary compatibility that nothing needs but
>> that we actually have code for just in case.
>
> But you put sysctl in features-removal-schedule.txt 3 years ago. :)

I did and before that the first version of the sysctl man page said
the binary values were not portable between kernels, so don't use
the system call.

> I believe they should see the kernel warnings if they are still using
> sysctl.

Unfortunately sometimes a word to the wise isn't quite enough. Sigh.  I
very much think having the sysctl code disabled by default is definitely
safe right now, and the first responsible step in getting this code
removed from the kernel.

There were two original reasons for the deprecations.  Maintaining the
binary sysctl logic was bug prone, and no one was using sysctl.  

The rewriting of the binary interface into binary_sysctl.c takes care of
most if not all of the maintenance concerns.  You may think you are
using the binary interface but the kernel just rewrites it into a /proc
access.

What is left is an interface in the kernel that no one uses and that
will eventually bit rot, for lack of care, attention, and testing, but we
still have a while until that happens.

I recommend this:

---
diff --git a/init/Kconfig b/init/Kconfig
index 2de5b1c..a9e1cda 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -808,7 +808,7 @@ config UID16
 config SYSCTL_SYSCALL
 	bool "Sysctl syscall support" if EMBEDDED
 	depends on PROC_SYSCTL
-	default y
+	default n
 	select SYSCTL
 	---help---
 	  sys_sysctl uses binary paths that have been found challenging
@@ -816,11 +816,15 @@ config SYSCTL_SYSCALL
 	  using paths with ascii names is now the primary path to this
 	  information.
 
-	  Almost nothing using the binary sysctl interface so if you are
-	  trying to save some space it is probably safe to disable this,
-	  making your kernel marginally smaller.
+	  This option is kept as a service to our loyal customers who
+	  have ignored all of our warnings over the years and have a
+	  binary somewhere that won't work without this.
+
+	  This code is not regularly used or tested and will probably have
+	  bit-rotted before someone cares enough to do more maintenance on it
+	  so enable at your own risk.
 
-	  If unsure say Y here.
+	  Say N here.
 
 config KALLSYMS
 	 bool "Load all symbols for debugging/ksymoops" if EMBEDDED

  reply	other threads:[~2010-10-20 13:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19  8:22 [PATCH 1/2] sysctl: refactor __do_proc_doulongvec_minmax() Amerigo Wang
2010-10-19  8:22 ` [PATCH 2/2] sysctl: remove sysctl syscall Amerigo Wang
2010-10-19 13:22   ` Andi Kleen
2010-10-19 13:49     ` Eric W. Biederman
2010-10-19 15:04       ` Andi Kleen
2010-10-19 16:00         ` Eric W. Biederman
2010-10-20  6:06           ` Cong Wang
2010-10-20 13:54             ` Eric W. Biederman [this message]
2010-10-21  9:26               ` Cong Wang
2010-10-19 14:10     ` Andreas Schwab
2010-10-19 15:05       ` Andi Kleen
2010-10-20  5:41         ` Cong Wang

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=m1zku99dh4.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ext-andriy.shevchenko@nokia.com \
    --cc=len.brown@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    /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