Re: [PATCH 2/2] sysctl: remove sysctl syscall

[Eric W. Biederman]

Cong Wang <amwang@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/