mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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