Modutils can't handle long kernel names

Modutils can't handle long kernel names

[Mike Fedyk]

Hello,

I've gotten into the habbit of adding the names of the patches I add to my
kernel to the extraversion string in the top level Makefile in my kernels.

Here's my latest example:
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 15
EXTRAVERSION=-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+ext3-mem_acct+elevator

Unfortunately, with this long kernel version number, modutils (I've noticed
depmod and modutils so far...) choke on it.

depmod:
depmod: Can't open /lib/modules/2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001/modules.dep for writing

uname -r:
2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001

uname -a:
Linux mikef-linux.matchmail.com 2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001 #1 SMP Thu Nov 8 20:18:04 PST 2001 i686 unknown

Yep, I know, "don't do that!".  Still, can this be fixed easily, or is it
one of those things that kbuild 2.5 will fix, and make everything rosy and
do my laundry too?

TIA,

Mike

Re: Modutils can't handle long kernel names

[Mike Fedyk]

On Thu, Nov 08, 2001 at 08:42:10PM -0800, Mike Fedyk wrote:
> Hello,
> 
> I've gotten into the habbit of adding the names of the patches I add to my
> kernel to the extraversion string in the top level Makefile in my kernels.
> 
> Here's my latest example:
> VERSION = 2
> PATCHLEVEL = 4
> SUBLEVEL = 15
> EXTRAVERSION=-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+ext3-mem_acct+elevator
> 
> Unfortunately, with this long kernel version number, modutils (I've noticed
> depmod and modutils so far...) choke on it.
> 
> depmod:
> depmod: Can't open /lib/modules/2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001/modules.dep for writing
> 
> uname -r:
> 2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001
> 
> uname -a:
> Linux mikef-linux.matchmail.com 2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001 #1 SMP Thu Nov 8 20:18:04 PST 2001 i686 unknown
> 

Oh, /proc/version looks good:
Linux version 2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+ext3-mem_acct+elevator (root@mikef-linux.matchmail.com) (gcc version 2.95.4 20011006 (Debian prerelease)) #1 SMP Thu Nov 8 20:18:04 PST 2001

Mike

Re: Modutils can't handle long kernel names

[Robert Love]

On Fri, 2001-11-09 at 00:23, Mike Fedyk wrote:
> I've gotten into the habbit of adding the names of the patches I add to my
> kernel to the extraversion string in the top level Makefile in my kernels.

Everything in-kernel is going to be OK because we set the version string
like so:

	char version[] = UTS_RELEASE;

where UTS_RELEASE is set from the variables in your Makefile.  Thus, the
string is set to the exact size of your version on compile.  If you find
anywhere _inside the kernel_ that breaks with long strings, it is
probably a bug.

Userspace is a different story.  In general, most programs probably do
not have dynamic off-the-heap storage for the version string size. 
Added such a feature may be advantageous in some cases, but in many it
is overkill and not worth the dynamic memory management.

I would consider the case where a large string crashes a user space
program a bug.  While the program may choose to set some limit, it
should certainly check its buffers.  I would also consider an abnormally
small legal string size a bug, but I honestly don't see your version
size fitting that description. :)

Anyhow, if you want to change it in a given app, its a simple size that
needs to be changed and then recompile.

	Robert Love

Re: Modutils can't handle long kernel names

[Keith Owens]

On Thu, 8 Nov 2001 20:42:10 -0800, 
Mike Fedyk <mfedyk@matchmail.com> wrote:
>EXTRAVERSION=-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+ext3-mem_acct+elevator
>
>Unfortunately, with this long kernel version number, modutils (I've noticed
>depmod and modutils so far...) choke on it.
>
>depmod:
>depmod: Can't open /lib/modules/2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001/modules.dep for writing
>
>uname -r:
>2.4.15-pre1+freeswan-1.91+xsched+netdev_random+ext3-0.9.15-2414+e#1 SMP Thu Nov 8 20:18:04 PST 2001

It is not a modutils problem, it is a fixed restriction on the size of
the uname() fields, modutils just uses what uname -r gives it.

         struct utsname {
                      char sysname[SYS_NMLN];
                      char nodename[SYS_NMLN];
                      char release[SYS_NMLN];
                      char version[SYS_NMLN];
                      char machine[SYS_NMLN];
                      char domainname[SYS_NMLN];
                      };

SYS_NMLN maps to _UTSNAME_LENGTH.
/* Length of the entries in `struct utsname' is 65.  */
#define _UTSNAME_LENGTH 65

Like you said, don't do that :).

Re: Modutils can't handle long kernel names

[andersg]

On Fri, Nov 09, 2001 at 04:34:00PM +1100, Keith Owens wrote:
> It is not a modutils problem, it is a fixed restriction on the size of
> the uname() fields, modutils just uses what uname -r gives it.

this patch would catch it at compiletime, wouldn't it?

-- 

//anders/g

--- Makefile.orig	Fri Nov  9 23:17:36 2001
+++ Makefile	Fri Nov  9 23:18:25 2001
@@ -338,7 +338,7 @@
 	@mv -f .ver $@
 
 init/version.o: init/version.c include/linux/compile.h include/config/MARKER
-	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c
+	$(CC) $(CFLAGS) -Werror $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c
 
 init/main.o: init/main.c include/config/MARKER
 	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) $(PROFILING) -c -o $*.o $<

Re: Modutils can't handle long kernel names

[Keith Owens]

On Fri, 9 Nov 2001 23:23:43 +0100, 
andersg@0x63.nu wrote:
>On Fri, Nov 09, 2001 at 04:34:00PM +1100, Keith Owens wrote:
>> It is not a modutils problem, it is a fixed restriction on the size of
>> the uname() fields, modutils just uses what uname -r gives it.
>
>this patch would catch it at compiletime, wouldn't it?
>--- Makefile.orig	Fri Nov  9 23:17:36 2001
>+++ Makefile	Fri Nov  9 23:18:25 2001
>@@ -338,7 +338,7 @@
> 	@mv -f .ver $@
> 
> init/version.o: init/version.c include/linux/compile.h include/config/MARKER
>-	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c
>+	$(CC) $(CFLAGS) -Werror $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c
> 
> init/main.o: init/main.c include/config/MARKER
> 	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) $(PROFILING) -c -o $*.o $<

Not quite.  If any of the fields are exactly 65 characters long
excluding the trailing NUL, gcc does not flag a warning.  Alas 65
characters trips the uname() bug.  It is arguable if
  char foo[65] = "65_printable_characters..........................................";
should cause a gcc warning or not, but it does not.

Also only some of the fields should cause a warning if they are too
long.  A domain name can legally be 255 characters and must not cause
an error when compiling the kernel.  So some fields must be truncated,
others must cause an error if they are too long.  The length checking
has to be done in the Makefile.

This patch fixes the problem of overlong utsname values.  Against
2.4.14, Linus, please apply.

Index: 14.1/Makefile
--- 14.1/Makefile Tue, 06 Nov 2001 12:07:56 +1100 kaos (linux-2.4/T/c/50_Makefile 1.1.2.15.1.2.2.25.2.2.1.17.1.4.1.29.1.19 644)
+++ 14.1(w)/Makefile Sat, 10 Nov 2001 15:23:44 +1100 kaos (linux-2.4/T/c/50_Makefile 1.1.2.15.1.2.2.25.2.2.1.17.1.4.1.29.1.19 644)
@@ -304,25 +304,29 @@ newversion:
 	. scripts/mkversion > .tmpversion
 	@mv -f .tmpversion .version
 
+uts_len		:= 64
+uts_truncate	:= sed -e 's/\(.\{1,$(uts_len)\}\).*/\1/'
+
 include/linux/compile.h: $(CONFIGURATION) include/linux/version.h newversion
-	@echo -n \#define UTS_VERSION \"\#`cat .version` > .ver
-	@if [ -n "$(CONFIG_SMP)" ] ; then echo -n " SMP" >> .ver; fi
-	@if [ -f .name ]; then  echo -n \-`cat .name` >> .ver; fi
-	@echo ' '`date`'"' >> .ver
+	@echo -n \#`cat .version` > .ver1
+	@if [ -n "$(CONFIG_SMP)" ] ; then echo -n " SMP" >> .ver1; fi
+	@if [ -f .name ]; then  echo -n \-`cat .name` >> .ver1; fi
+	@echo ' '`date` >> .ver1
+	@echo \#define UTS_VERSION \"`cat .ver1 | $(uts_truncate)`\" > .ver
 	@echo \#define LINUX_COMPILE_TIME \"`date +%T`\" >> .ver
 	@echo \#define LINUX_COMPILE_BY \"`whoami`\" >> .ver
-	@echo \#define LINUX_COMPILE_HOST \"`hostname`\" >> .ver
-	@if [ -x /bin/dnsdomainname ]; then \
-	   echo \#define LINUX_COMPILE_DOMAIN \"`dnsdomainname`\"; \
-	 elif [ -x /bin/domainname ]; then \
-	   echo \#define LINUX_COMPILE_DOMAIN \"`domainname`\"; \
-	 else \
-	   echo \#define LINUX_COMPILE_DOMAIN ; \
-	 fi >> .ver
+	@echo \#define LINUX_COMPILE_HOST \"`hostname | $(uts_truncate)`\" >> .ver
+	@([ -x /bin/dnsdomainname ] && /bin/dnsdomainname > .ver1) || \
+	 ([ -x /bin/domainname ] && /bin/domainname > .ver1) || \
+	 echo > .ver1
+	@echo \#define LINUX_COMPILE_DOMAIN \"`cat .ver1 | $(uts_truncate)`\" >> .ver
 	@echo \#define LINUX_COMPILER \"`$(CC) $(CFLAGS) -v 2>&1 | tail -1`\" >> .ver
 	@mv -f .ver $@
+	@rm -f .ver1
 
 include/linux/version.h: ./Makefile
+	@expr length "$(KERNELRELEASE)" \<= $(uts_len) > /dev/null || \
+	  (echo KERNELRELEASE \"$(KERNELRELEASE)\" exceeds $(uts_len) characters >&2; false)
 	@echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
 	@echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
 	@echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver

Re: Modutils can't handle long kernel names

[Thomas Dodd]

Keith Owens wrote:

> On Fri, 9 Nov 2001 23:23:43 +0100, 
> andersg@0x63.nu wrote:
>>On Fri, Nov 09, 2001 at 04:34:00PM +1100, Keith Owens wrote:
>>> It is not a modutils problem, it is a fixed restriction on the size of
>>> the uname() fields, modutils just uses what uname -r gives it.

> +uts_len		:= 64
> +uts_truncate	:= sed -e 's/\(.\{1,$(uts_len)\}\).*/\1/'


Should this be a fixed length of 64?
Or should it be grabbed form a header somewhere?
So when/if SYS_NMLN/_UTSNAME_LENGTH is changed
longer strings can be used? I check and Solaris 8
defines SYS_NMLN as 257.

Would this break cross-comiling badly?
Are other libc headers needed in the build?

	-Thomas

Re: Modutils can't handle long kernel names

[Keith Owens]

On Wed, 14 Nov 2001 16:04:38 -0600, 
Thomas Dodd <ted@cypress.com> wrote:
>Keith Owens wrote:
>> +uts_len		:= 64
>> +uts_truncate	:= sed -e 's/\(.\{1,$(uts_len)\}\).*/\1/'
>
>Should this be a fixed length of 64?
>Or should it be grabbed form a header somewhere?
>So when/if SYS_NMLN/_UTSNAME_LENGTH is changed
>longer strings can be used? I check and Solaris 8
>defines SYS_NMLN as 257.
>
>Would this break cross-comiling badly?
>Are other libc headers needed in the build?

This is the kernel's idea of uts length, not glibc, it is independent
of where you are compiling.  It could be extracted from the kernel
header,
  uts_len := $(shell sed -ne 's/#define __NEW_UTS_LEN //p' include/linux/utsname.h)
but why bother?  The value has been fixed at 64 since at least 2.0 and
is embedded in glibc so it is unlikely to change.  Even if it does
change, it must be upwards so the worst case is fail safe.