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

[Eric W. Biederman]

Andi Kleen <ak@xxxxxxxxxxxxxxx> writes:

>> At the time the deprecation was written we nearly we were in the late
>> rc's before anything that cared in practice. glibc has stopped even
>> providing a sys_sysctl wrapper now.
>
> What matters are old glibc installations, not new ones.

No.  It matters a lot that glibc has stopped providing the wrapper, as
that makes it doubly difficult for new users to start using the binary
sysctl interface.

>>> I think it's ok to remove the full tables, but keeping
>>> a wrapper just for the functionality glibc use(s/d) is still a good
>>> idea.
>> I think the only problem should be the arm glibc.  I don't know if
>> it's iopl implementation ever got weened off of this.  I tried
>> but I didn't have good test machine and submitting patches to
>> glibc is much more of a pain than kernel patches.
>
>
> Eric, I think you have the wrong approach here: it doesn't matter what new glibc
> does,
> but what any old glibcs do. If any old one uses it we cannot simply
> remove it.

????  If there are any current users we can not remove it.

If current glibc on arm still uses this (which I expect it does) we can
not possibly remove the code.  With a current user it doesn't matter
what historical versions of glibc do.

>> To my knowledge there has never been a version of x86 glibc that
>> had problems if sys_sysctl returns -ENOSYS, and glibc proper removed
>> even that dependency almost as soon as sys_sysctl was deprecated.
>>
>
> AFAIK older glibc didn't use some functionality in the kernel if they couldn't
> figure out the right kernel version. And they were using sysctl for
> this.

Sigh.  We have had the conversation a dozen times.

I have looked and reasearched until I am bored.  It was the pthreads
code attempting to detect if we are smp.  At worst the code would not
optimize for the uniprocessor case.

But again that was long ago, and last time we had this conversation it
was impossible for me to find glibc binaries on x86 that were still even
trying to do this. 

We have been warning on even the historical glibc pthreads usage for
over a year now.

>> Last time we discussed this (when I added the compatibility wrapper)
>> I couldn't even find a version of glibc that used sysctl, and I could
>> not find a distribution old enough that still had a version of glibc
>> that used sysctl on x86.
>
> When I did my really old work for sysctl_binary() I ran into this problem.
> All glibc binaries on my distribution back then used sysctl.

Yep.  Which was what 4+ years ago?

Perhaps the question should be in practice does any enterprise distro
have a glibc that uses sys_sysctl.  Not that I think even that case
is particularly interesting.

>> We warn on every sys_sysctl value now even the glibc uses and perhaps I
>> am blind but I haven't seen any bug reports.  So we should be safe
>> turning this off.
>>
>
> I don't so. I don't think we can that easily break compatibility, sorry.
> Binary compatibility is something very important for Linux.

Duh!  Which is why we have the code.

Of course the safe course is to keep the code and disable the feature,
if no one is using it.

> Anyways I'm fine with removing the bulk of the tables, but not the compat
> table for the one glibc uses.

Removing the bulk of the tables is another name for breaking binary
compatibility.  Which you said is a no no.  We have the code and it
works at this point, there is no point to neutering it.  Especially when
distros whose glibc pthread code used this are for the most part lost in
the course of history.

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.

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.

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/