Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

Eric W. Biederman
2009-11-10T04:42:54Z

Arnd Bergmann <arnd@arndb.de> writes:

> On Monday 09 November 2009, Andi Kleen wrote:
>> >
>> > So? Most users of old glibc are also using old kernels, and they
>>
>> How do you know? At least here it's quite common to use new kernels
>> with old user land.
>
> If by 'here' you mean kernel developers, sure. Other people I'd
> assume typically run whatever comes with the distro, and that
> usually includes both a libc and a kernel.

The question with respect to my patchset. Is the increase in time
a measurable performace regression or is the cost lost in the noise?

Andi do you know of a way to measure this?

Doing a special case for /proc/sys/kernel/version if someone can
measure the overhead seem sane. But the double maintenance isn't
my idea of fun.

The code involved would need to look something like:

if (len > sizeof(current->nsporxy->uts_ns.name.version)
len = sizeof(current->nsporxy->uts_ns.name.version);
down_read(&uts_sem);
ret = copy_to_user(buf, current->nsproxy->uts_ns.name.version, len);
up_read(&uts_sem);

That isn't a particular pretty expression, and it has a much higher chance
of bitrotting than what I have now.

>> > can still use the config option for the compatibility code.
>> > There wouldn't even be a performance penalty over new glibc with
>> > new kernels which already use procfs.
>>
>> When he drops the sysctl(2) API completely the old userland will
>> be unhappy.
>
> I did not get the impression that this was the plan. Maybe I missed
> something, but the work that Eric did seemed to be strategic for
> leaving the code around for a really long time without causing any
> maintainance pain that the current code does.
>
> It will be years before we can really remove that code, but distros
> can start disabling it (or making it modular) earlier than that
> when they feel the time has come to stop support for static binaries
> using sysctl (there should really be few of those).

There is always the question if we can get away with it. I intend to
submit a patch that changes the default to off. Beyond that I don't
don't know. I expect folks doing enterprise distro would want to turn
of sys_sysctl because it is a typically buggy. Why chance bitrot leading
to a security hole?

Eric