From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sysctl: Allow /proc/sys without sys_sysctl
Date: Wed, 12 Jul 2006 08:47:17 -0600 [thread overview]
Message-ID: <m1ac7edgne.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200607121532.05227.ak@suse.de> (Andi Kleen's message of "Wed, 12 Jul 2006 15:32:05 +0200")
Andi Kleen <ak@suse.de> writes:
> On Wednesday 12 July 2006 05:13, Eric W. Biederman wrote:
>> Andi Kleen <ak@suse.de> writes:
>> > ebiederm@xmission.com (Eric W. Biederman) writes:
>> >> Since sys_sysctl is deprecated start allow it to be compiled out.
>> >> This should catch any remaining user space code that cares,
>> >
>> > I tried this long ago, but found that glibc uses sysctl in each
>> > program to get the kernel version. It probably handles ENOSYS,
>> > but there might be slowdowns or subtle problems from it not knowing
>> > the kernel version.
>> >
>> > So I think it's ok to remove the big sysctl, but at a very minimal
>> > replacement that just handles (CTL_KERN, KERN_VERSION) is needed.
>>
>> If glibc is looking at kernel.osrelease it might make sense.
>> If glibc is looking at kernel.version which is just the build number
>> and date I can't imagine a correct usage.
>
> It's KERN_VERSION
>
>>From my /bin/ls:
>
> _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfc8e1e0, 30, (nil), 0}) = 0
Yep. I found it.
In glibc (2.3.6, 2.4, and CVS) nptl/sysdeps/unix/sysv/linux/smp.h
>
> /* Test whether the machine has more than one processor. This is not the
> best test but good enough. More complicated tests would require `malloc'
> which is not available at that time. */
> static inline int
> is_smp_system (void)
> {
> static const int sysctl_args[] = { CTL_KERN, KERN_VERSION };
> char buf[512];
> size_t reslen = sizeof (buf);
>
> /* Try reading the number using `sysctl' first. */
> if (__sysctl ((int *) sysctl_args,
> sizeof (sysctl_args) / sizeof (sysctl_args[0]),
> buf, &reslen, NULL, 0) < 0)
> {
> /* This was not successful. Now try reading the /proc filesystem. */
> int fd = open_not_cancel_2 ("/proc/sys/kernel/version", O_RDONLY);
> if (__builtin_expect (fd, 0) == -1
> || (reslen = read_not_cancel (fd, buf, sizeof (buf))) <= 0)
> /* This also didn't work. We give up and say it's a UP machine. */
> buf[0] = '\0';
>
> close_not_cancel_no_status (fd);
> }
>
> return strstr (buf, "SMP") != NULL;
> }
So it will correctly handle that sysctl being compiled out, and
the fallback to using /proc. The code seems to have been
doing that since it was added to glibc in 2000.
It only uses it to see if it should busy wait when taking a mutex.
If the kernel has SMP support is lousy predictor if it makes sense
for glibc to busy wait. Darn optimizations for the contended case.
>> If this usage is still common in glibc we can decide what to do
>> when the warnings pop up.
>
> printk for everything would annoy basically everybody. Not a good idea.
Well everything isn't using pthreads. Why ls uses pthreads
is beyond me.
Anyway it looks like it's time to send of a patch.
Eric
next prev parent reply other threads:[~2006-07-12 14:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-10 22:38 Eric W. Biederman
2006-07-10 22:48 ` Randy.Dunlap
2006-07-11 4:00 ` Eric W. Biederman
2006-07-11 4:19 ` Andrew Morton
2006-07-11 6:57 ` Eric W. Biederman
2006-07-11 7:04 ` Andrew Morton
2006-07-11 7:52 ` Eric W. Biederman
2006-07-11 8:05 ` Andrew Morton
2006-07-11 7:23 ` [PATCH] sysctl: Scream if someone uses sys_sysctl Eric W. Biederman
2006-07-11 22:26 ` [PATCH] sysctl: Allow /proc/sys without sys_sysctl Andi Kleen
2006-07-12 3:13 ` Eric W. Biederman
2006-07-12 13:32 ` Andi Kleen
2006-07-12 14:47 ` Eric W. Biederman [this message]
2006-07-12 14:52 ` Andi Kleen
2006-07-12 15:32 ` Eric W. Biederman
2006-07-12 16:08 ` Andi Kleen
2006-07-12 16:36 ` Eric W. Biederman
2006-07-12 18:24 ` Stephen Hemminger
2006-07-12 19:58 ` Arjan van de Ven
2006-07-13 0:52 ` Theodore Tso
2006-07-14 20:09 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1ac7edgne.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome