[2.6 patch] unexport uts_sem

[2.6 patch] unexport uts_sem

[Adrian Bunk]

I didn't find any possible modular usage in the kernel.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.11-rc5-mm1-full/kernel/sys.c.old	2005-03-04 01:19:18.000000000 +0100
+++ linux-2.6.11-rc5-mm1-full/kernel/sys.c	2005-03-04 01:19:29.000000000 +0100
@@ -1382,8 +1382,6 @@
 
 DECLARE_RWSEM(uts_sem);
 
-EXPORT_SYMBOL(uts_sem);
-
 asmlinkage long sys_newuname(struct new_utsname __user * name)
 {
 	int errno = 0;

Re: [2.6 patch] unexport uts_sem

[Alan Cox]

On Gwe, 2005-03-04 at 00:50, Adrian Bunk wrote:
> I didn't find any possible modular usage in the kernel.

Sure ? This used to be exported for loadable modules that wanted to get
the system default hostname string and for emulation layers like xabi
(the SYS5 unix emulation lib)

Alan

Re: [2.6 patch] unexport uts_sem

[Arjan van de Ven]

On Fri, 2005-03-04 at 12:57 +0000, Alan Cox wrote:
> On Gwe, 2005-03-04 at 00:50, Adrian Bunk wrote:
> > I didn't find any possible modular usage in the kernel.
> 
> Sure ? This used to be exported for loadable modules that wanted to get
> the system default hostname string and for emulation layers like xabi
> (the SYS5 unix emulation lib)

afaik the linux abi stuff never made the jump to 2.6, and is far from
likely to do so...

[2.6 patch] unexport uts_sem

[Adrian Bunk]

I didn't find any possible modular usage in the kernel.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 4 Mar 2005

--- linux-2.6.11-rc5-mm1-full/kernel/sys.c.old	2005-03-04 01:19:18.000000000 +0100
+++ linux-2.6.11-rc5-mm1-full/kernel/sys.c	2005-03-04 01:19:29.000000000 +0100
@@ -1382,8 +1382,6 @@
 
 DECLARE_RWSEM(uts_sem);
 
-EXPORT_SYMBOL(uts_sem);
-
 asmlinkage long sys_newuname(struct new_utsname __user * name)
 {
 	int errno = 0;

[2.6 patch] unexport uts_sem

[Adrian Bunk]

With the removal of the Solaris binary emulation the export of 
uts_sem became unused.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
e15db7b262fd8c3d9000e7d5e7a2b1d720fba8de diff --git a/kernel/sys.c b/kernel/sys.c
index 6a0cc71..773d4a5 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1331,8 +1331,6 @@ EXPORT_SYMBOL(in_egroup_p);
 
 DECLARE_RWSEM(uts_sem);
 
-EXPORT_SYMBOL(uts_sem);
-
 asmlinkage long sys_newuname(struct new_utsname __user * name)
 {
 	int errno = 0;

Re: [2.6 patch] unexport uts_sem

[David Miller]

From: Adrian Bunk <bunk@kernel.org>
Date: Wed, 23 Apr 2008 12:52:15 +0300

> With the removal of the Solaris binary emulation the export of 
> uts_sem became unused.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>

Acked-by: David S. Miller <davem@davemloft.net>

[2.6 patch] unexport uts_sem

[Adrian Bunk]

With the removal of the Solaris binary emulation the export of 
uts_sem became unused.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: David S. Miller <davem@davemloft.net>

---

This patch has been sent on:
- 23 Apr 2008

e15db7b262fd8c3d9000e7d5e7a2b1d720fba8de diff --git a/kernel/sys.c b/kernel/sys.c
index 6a0cc71..773d4a5 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1331,8 +1331,6 @@ EXPORT_SYMBOL(in_egroup_p);
 
 DECLARE_RWSEM(uts_sem);
 
-EXPORT_SYMBOL(uts_sem);
-
 asmlinkage long sys_newuname(struct new_utsname __user * name)
 {
 	int errno = 0;

Re: [2.6 patch] unexport uts_sem

[Frank Ch. Eigler]

Adrian Bunk <bunk@kernel.org> writes:

> With the removal of the Solaris binary emulation the export of 
> uts_sem became unused. [...]
>
> -EXPORT_SYMBOL(uts_sem);

Am I correct that this would makes it invalid for modules to call
utsname() (since the protective semaphore is now hidden)?  Systemtap
has been using them in order to validate the modules it builds against
possible kernel vs. kernel-devel differences.

- FChE

Re: [2.6 patch] unexport uts_sem

[Christoph Hellwig]

On Tue, May 20, 2008 at 01:16:19PM -0400, Frank Ch. Eigler wrote:
> Am I correct that this would makes it invalid for modules to call
> utsname() (since the protective semaphore is now hidden)?

Yesm they should never had done that anyway.  The module support
does it's own version checking already.

Re: [2.6 patch] unexport uts_sem

[Frank Ch. Eigler]

Hi -

On Tue, May 20, 2008 at 01:27:30PM -0400, Christoph Hellwig wrote:
> > Am I correct that this would makes it invalid for modules to call
> > utsname() (since the protective semaphore is now hidden)?
> 
> Yesm they should never had done that anyway.  The module support
> does it's own version checking already.

Sorry, I misspoke - this check is intended not to cross-check
kernel-devel and the kernel itself, but the debuginfo or similar data
that is given to describe target of a systemtap script.  I guess for
new enough kernels we'll just do that using buildid hash codes.

By the way, there do appear to be a few suspect in-tree users of
utsname() without uts_sem locking (usb/storage/usb.c, cifs/connect.c,
char/random.cc, fs/lockd/clntproc.c, ...).  If these need to be fixed,
then wouldn't uts_sem need to come back exported?

- FChE

Re: [2.6 patch] unexport uts_sem

[Christoph Hellwig]

On Tue, May 20, 2008 at 02:38:02PM -0400, Frank Ch. Eigler wrote:
> Sorry, I misspoke - this check is intended not to cross-check
> kernel-devel and the kernel itself, but the debuginfo or similar data
> that is given to describe target of a systemtap script.  I guess for
> new enough kernels we'll just do that using buildid hash codes.
> 
> By the way, there do appear to be a few suspect in-tree users of
> utsname() without uts_sem locking (usb/storage/usb.c

Just a debug printk.  Note sure why this particular one needs to
print the version, but if it really wants to do it it should rather use
UTS_RELEASE.

> cifs/connect.c,

This one is quite fishy. Not sure what it needs the name for but the
kernel utsname is probably a bad choise.  And yes, this one actually
is racy because the host name can change.

> char/random.c,

random.c is always built-in and utsname is called during the
single-threaded kernel initialization phase, so this is safe.

> fs/lockd/clntproc.c, ...).

Yes, this one is racy.  Should probably be fixed by starting lockd
with CLONE_NEWUTS so that it never changed during it's lifetime.
It's probably not a good idea when it changes with outstanding lockd
request anyway.

> If these need to be fixed,
> then wouldn't uts_sem need to come back exported?