Re: [PATCH] SYSCTL: Fix sysctl breakage on systems with older glibc

[Eric W. Biederman]

Andi Kleen <andi@xxxxxxxxxxxxxx> writes:

> On Thu, Dec 17, 2009 at 07:07:54AM -0800, Eric W. Biederman wrote:
>> reaction would be.  If it makes logging in and manually using the
>> machine unbearable on systems with versions of glibc from days of
>> yore, the level of logging is too high.
>
> The reason I was slightly annoyed is because I flagged this 
> during code review and it wasn't addressed before merging.

No, you did not flag that in the review.

You said the performance would get worse with my implementation, which
is something else entirely.  I did not change anything when I
discovered that versions of glibc old enough to still have that code
were rare enough I could not find one installed anywhere.

>> > I see this on a SUSE 10.0 system with glibc 2.3.5.
>> > Don't warn for this common case.
>> 
>> Perhaps it is just my sample of the world but glibc < 2.5 isn't
>> common, especially on machines that I am putting new kernels on.
>> Equally machines with 3+ year old installs are rare.
>
> Linux simply cannot abandon older user land. We still (near) 
> fully support a.out executables, even on 64bit.

You think what I have done is abandonment of userland?

My position is and has been since I added the entry to
Docuementation/feature-removal.txt that actual real applications that
care about binary sysctls are so rare as to be practically
non-existent, and that the maintenance practices of the binary sysctl
interface show that we abandoned those applications long ago.

One of the signs of this abandonment of the binary sysctl interface is
that no one has ever done a proper 32/64 interface for it, and we do
have 4 sysctls where this actually matters.

I rewrote all of the binary sysctls in terms of their ascii
counterparts so that there would be a reasonable chance that they
would continue to work for as long as we need them.

So I think I have gone above and beyond in my effort to keep from
abandoning the one program out there that actually cares.

As for glibc.  The usage in glibc before glibc 2.5 does not count as a
user space application that cares.  You can return any string or
-ENOSYS and glibc works fine.  In addition to the fact that glibc will
read from proc if sysctl(2) fails it.

>> > Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
>> >
>> > diff -u linux-2.6.32-git12/kernel/sysctl_binary.c-o linux-2.6.32-git12/kernel/sysctl_binary.c
>> > --- linux-2.6.32-git12/kernel/sysctl_binary.c-o	2009-12-16 12:15:52.000000000 +0100
>> > +++ linux-2.6.32-git12/kernel/sysctl_binary.c	2009-12-16 12:14:58.000000000 +0100
>> > @@ -1399,6 +1399,13 @@
>> >  {
>> >  	int i;
>> >  
>> > +	/* 
>> > +	 * CTL_KERN/KERN_VERSION is used by older glibc and cannot 
>> > +	 * ever go away.
>> > +	 */
>> The comment is wrong.  Older versions of glibc are perfectly happy
>> getting -ENOSYS form sys_sysctl.
>
> and it fills and fills and fills the kernel log. In practice
> that's not usable.

Which is why I think a printk_once is the right solution.

>> > +	if (name[0] == CTL_KERN && name[1] == KERN_VERSION)
>> > +		return;
>> 
>> If you make it printk_once for this case I think that strikes the right
>> balance.  You won't be spammed to death by messages telling you about
>> a silly old glibc, but you will be told.
>
> It's not a "silly old glibc", it's a "perfectly functional old glibc"

It is a perfectly functional silly old glibc.  It does silly things so
I will call it silly.  I don't intend to deliberately break it but I
don't intend to encourage it's silly behavior or it's use either.

The real issue is I don't know that only glibc ever calls CTL_KERN
KERN_VERSION.  We have not been warning about it for years.  So if
there is some userspace application out there besides glibc I want to
warn them.

I want to warn because for all practical purposes we abandoned
sysctl(2) a long time ago.  For now I have tested and verified my
wrapper works.  I expect my wrapper to work for the foreseeable
future.  However since nothing uses sysctl(2) that cares ultimately
the code will bit rot and fail.  I would like whatever random
userspace applications are out there to have a chance to migrate
to something we actually maintain before that happens.

To give that warning teeth that people will believe I have to continue
to say I am going to remove sysctl.  I do honestly intend in another
year when the deadline rolls around to turn sysctl(2) off by default.
I would be truly surprised if anyone noticed.

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