Message-ID: <4CC00740.3050404@redhat.com>
Date:	Thu, 21 Oct 2010 17:26:24 +0800
From:	Cong Wang <amwang@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Len Brown <len.brown@...el.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Eric Paris <eparis@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andy Shevchenko <ext-andriy.shevchenko@...ia.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/2] sysctl: remove sysctl syscall

On 10/20/10 21:54, Eric W. Biederman wrote:
> Cong Wang<amwang@...hat.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.


Ok, got it.


>> 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:


This sounds ok for me.
Do you want to me to carry this patch for you and resend?

>
> ---
> 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


Thanks!
--
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