[PATCH] binfmt_misc.c, kernel-2.4.12

[PATCH] binfmt_misc.c, kernel-2.4.12

[Albert Bartoszko]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Hello

I find bug in  binfmt_misc.c from kernel 2.4.12 source. The read() syscal
return bad value, causes some application SIGSEGV.

Example:

# modprobe binfmt_misc
# echo ':Java:M::\xca\xfe\xba\xbe::/usr/local/bin/javawrapper:'
>/proc/sys/fs/binfmt_misc/register

# strace less /proc/sys/fs/binfmt_misc/Java
...............................................................
...............................................................
open("/proc/sys/fs/binfmt_misc/Java", O_RDONLY) = 3
lseek(3, 1, SEEK_SET)                   = 1
lseek(3, 0, SEEK_SET)                   = 0
read(3, "enabled\ninterpreter /usr/local/b"..., 64) = 71

^^^^^^^^
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

I send a patch I wrote that correct this problem and do same cleanup, so
source and object are a bit smaller.

Albert Bartoszko
albertb@nt.kegel.com.pl



[-- Attachment #2: binfmt_misc.patch --]
[-- Type: application/octet-stream, Size: 1725 bytes --]

--- /usr/src/linux/fs/binfmt_misc.c.org	Fri Feb  9 20:29:44 2001
+++ /usr/src/linux/fs/binfmt_misc.c	Fri Oct 19 02:32:24 2001
@@ -13,6 +13,8 @@
  *  1997-06-26 hpa: pass the real filename rather than argv[0]
  *  1997-06-30 minor cleanup
  *  1997-08-09 removed extension stripping, locking cleanup
+ *  2001-10-15 Albert Bartoszko: cleanup, 
+ *		correct return value of proc_read_status()
  */
 
 #include <linux/config.h>
@@ -354,28 +356,19 @@
 	char *dp;
 	int elen, i, err;
 
-#ifndef VERBOSE_STATUS
-	if (data) {
+	if (!data) 
+	    sprintf(page, "%s\n", "enabled");
+	else {
 		if (!(e = get_entry((int) data))) {
 			err = -ENOENT;
 			goto _err;
-		}
-		i = e->flags & ENTRY_ENABLED;
-		put_entry(e);
-	} else {
-		i = enabled;
-	} 
-	sprintf(page, "%s\n", (i ? "enabled" : "disabled"));
+		} 
+#ifndef VERBOSE_STATUS		
+    		sprintf(page, "%s\n", 
+			(e->flags & ENTRY_ENABLED) ? "enabled" : "disabled");
 #else
-	if (!data)
-		sprintf(page, "%s\n", (enabled ? "enabled" : "disabled"));
-	else {
-		if (!(e = get_entry((long) data))) {
-			err = -ENOENT;
-			goto _err;
-		}
-		sprintf(page, "%s\ninterpreter %s\n",
-		        (e->flags & ENTRY_ENABLED ? "enabled" : "disabled"),
+		sprintf(page, "%s\ninterpreter %s\n", 
+			(e->flags & ENTRY_ENABLED) ? "enabled" : "disabled",	
 			e->interpreter);
 		dp = page + strlen(page);
 		if (!(e->flags & ENTRY_MAGIC)) {
@@ -399,13 +392,14 @@
 			*dp++ = '\n';
 			*dp = '\0';
 		}
-		put_entry(e);
-	}
 #endif
-
+		put_entry(e);	
+	}
 	elen = strlen(page) - off;
 	if (elen < 0)
 		elen = 0;
+	if (elen > count)
+		elen = count;
 	*eof = (elen <= count) ? 1 : 0;
 	*start = page + off;
 	err = elen;

[-- Attachment #3: README --]
[-- Type: application/octet-stream, Size: 103 bytes --]

SUBJECT: Patch for bad return value in binfmt_misc.c, AUTHOR:Albert Bartoszko <albertb@nt.kegel.com.pl>

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Fri, 19 Oct 2001, Albert Bartoszko wrote:

> Hello
> 
> I find bug in  binfmt_misc.c from kernel 2.4.12 source. The read() syscal

	only one?

> return bad value, causes some application SIGSEGV.

Hardly a surprise.  Not everything that passes compiler is valid C.
Stuff in fs/binfmt_misc.c from Linus' tree isn't.  Pick one from -ac
+ corresponding change in fs/proc/root.c (again, see -ac).  Variant
in Linus' tree is complete crap.

<goes back to sleep>

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Richard Guenther]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1142 bytes --]

Hi Linus,

As Al pissed me off again with complaining about binfmt_misc, please
apply the attached patch which corrects the 'not C code' line and
fixes the problem Albert noticed. This doesnt fix various assumptions
about the /proc code that were either valid at the time of writing
binfmt_misc or badly/not documented.

Feel free to use binfmt_misc version from -ac, I'm sure Al will take
responsibility of maintaining that crappy version then.

Thanx, Richard.

On Fri, 19 Oct 2001, Alexander Viro wrote:
> On Fri, 19 Oct 2001, Albert Bartoszko wrote:
> > Hello
> >
> > I find bug in  binfmt_misc.c from kernel 2.4.12 source. The read() syscal
>
> 	only one?
>
> > return bad value, causes some application SIGSEGV.
>
> Hardly a surprise.  Not everything that passes compiler is valid C.
> Stuff in fs/binfmt_misc.c from Linus' tree isn't.  Pick one from -ac
> + corresponding change in fs/proc/root.c (again, see -ac).  Variant
> in Linus' tree is complete crap.
>
> <goes back to sleep>

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2092 bytes --]

--- /home/kobras/tatadm/kernel/linux-2.4.3-UP/fs/binfmt_misc.c	Fri Feb  9 20:29:44 2001
+++ binfmt_misc.c	Fri Oct 19 15:26:32 2001
@@ -13,6 +13,8 @@
  *  1997-06-26 hpa: pass the real filename rather than argv[0]
  *  1997-06-30 minor cleanup
  *  1997-08-09 removed extension stripping, locking cleanup
+ *  2001-10-15 Albert Bartoszko: cleanup, 
+ *		correct return value of proc_read_status()
  */
 
 #include <linux/config.h>
@@ -300,9 +302,7 @@
 
 	e->proc_name = copyarg(&dp, &sp, &cnt, del, 0, &err);
 
-	/* we can use bit 3 of type for ext/magic
-	   flag due to the nice encoding of E and M */
-	if ((*sp & ~('E' | 'M')) || (sp[1] != del))
+	if ((*sp != 'E' && *sp != 'M') || (sp[1] != del))
 		err = -EINVAL;
 	else
 		e->flags = (*sp++ & (ENTRY_MAGIC | ENTRY_ENABLED));
@@ -354,28 +354,19 @@
 	char *dp;
 	int elen, i, err;
 
-#ifndef VERBOSE_STATUS
-	if (data) {
+	if (!data) 
+	    sprintf(page, "%s\n", "enabled");
+	else {
 		if (!(e = get_entry((int) data))) {
 			err = -ENOENT;
 			goto _err;
-		}
-		i = e->flags & ENTRY_ENABLED;
-		put_entry(e);
-	} else {
-		i = enabled;
-	} 
-	sprintf(page, "%s\n", (i ? "enabled" : "disabled"));
+		} 
+#ifndef VERBOSE_STATUS		
+    		sprintf(page, "%s\n", 
+			(e->flags & ENTRY_ENABLED) ? "enabled" : "disabled");
 #else
-	if (!data)
-		sprintf(page, "%s\n", (enabled ? "enabled" : "disabled"));
-	else {
-		if (!(e = get_entry((long) data))) {
-			err = -ENOENT;
-			goto _err;
-		}
-		sprintf(page, "%s\ninterpreter %s\n",
-		        (e->flags & ENTRY_ENABLED ? "enabled" : "disabled"),
+		sprintf(page, "%s\ninterpreter %s\n", 
+			(e->flags & ENTRY_ENABLED) ? "enabled" : "disabled",	
 			e->interpreter);
 		dp = page + strlen(page);
 		if (!(e->flags & ENTRY_MAGIC)) {
@@ -399,13 +390,14 @@
 			*dp++ = '\n';
 			*dp = '\0';
 		}
-		put_entry(e);
-	}
 #endif
-
+		put_entry(e);	
+	}
 	elen = strlen(page) - off;
 	if (elen < 0)
 		elen = 0;
+	if (elen > count)
+		elen = count;
 	*eof = (elen <= count) ? 1 : 0;
 	*start = page + off;
 	err = elen;

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Fri, 19 Oct 2001, Richard Guenther wrote:

> Hi Linus,
> 
> As Al pissed me off again with complaining about binfmt_misc, please
> apply the attached patch which corrects the 'not C code' line and
> fixes the problem Albert noticed. This doesnt fix various assumptions
> about the /proc code that were either valid at the time of writing
> binfmt_misc or badly/not documented.

Like, say it, "thou shalt not dereference user-supplied pointers for verily,
copy_from_user() is there for purpose"?

Or "tons of blind sprintf() calls can really ruin your day when you overflow
the buffer"?

Or that checking the values of arguments, while a noble thing, should
be done _before_ you use them?

Or, say it, one about meaning of
        if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
not being the same as
        if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
Darn that Ritchie guy - he should've documented that stuff.  Oh, wait -
he had actually done that...

Please, learn C.  Then learn some basic stuff about kernel programming.
Then feel free to start mouthing off.

As for the version in -ac and maintaining it - sure I will.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Richard Guenther]

On Fri, 19 Oct 2001, Alexander Viro wrote:

> On Fri, 19 Oct 2001, Richard Guenther wrote:
> 
> > Hi Linus,
> > 
> > As Al pissed me off again with complaining about binfmt_misc, please
> > apply the attached patch which corrects the 'not C code' line and
> > fixes the problem Albert noticed. This doesnt fix various assumptions
> > about the /proc code that were either valid at the time of writing
> > binfmt_misc or badly/not documented.

As binfmt_misc write access is root only, I didnt care to check
too much as root can shoot himself anyway. Some places could use
more checking, some even less.

> Or, say it, one about meaning of
>         if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
> not being the same as
>         if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {

Err, who said that it is the same?? Its sufficient, if you trust
root to just pass '0' or '1'. Ok, its probably too clever for the
average C programmer, but it seems I didnt care.

> Please, learn C.  Then learn some basic stuff about kernel programming.
> Then feel free to start mouthing off.

Well, try to get some basic communication style and you'll even
get a long with guys like me.

> As for the version in -ac and maintaining it - sure I will.

Just get Linus to take the -ac version then. I'm sick to read
your comments about binfmt_misc over and over again. You've
made your point(s) - more than one time. Thats enough. Welcome
to my killfile now.

Richard.

--
Richard Guenther <richard.guenther@student.uni-tuebingen.de>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Fri, 19 Oct 2001, Richard Guenther wrote:

> > Or, say it, one about meaning of
> >         if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
> > not being the same as
> >         if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
> 
> Err, who said that it is the same?? Its sufficient, if you trust
> root to just pass '0' or '1'. Ok, its probably too clever for the
> average C programmer, but it seems I didnt care.

	If you trust root to pass '0' or '1' - (count == 1) would do nicely.
And sorry, but "clever" is not the word that comes to mind.  "Not having a
clue on the meaning of bitwise operations" would be more accurate.

> > As for the version in -ac and maintaining it - sure I will.
> 
> Just get Linus to take the -ac version then. I'm sick to read

<shrug> might be a good idea.  The thing is extremely sloppy and considering
the blatant "I'm t00 l33t t0 F1X 7h4t" attitude of maintainer...

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Albert Bartoszko]

> > I find bug in  binfmt_misc.c from kernel 2.4.12 source. The read()
syscal
>
> only one?

"Gutta cavat lapidem non vi, sed saepe cadendo"

>
> > return bad value, causes some application SIGSEGV.
>
> Hardly a surprise.  Not everything that passes compiler is valid C.
> Stuff in fs/binfmt_misc.c from Linus' tree isn't.  Pick one from -ac
> + corresponding change in fs/proc/root.c (again, see -ac).  Variant
> in Linus' tree is complete crap.

You are sarcastic.

I do it. And:

# uname -a
Linux xxxx 2.4.12-ac3 #1 Sun Oct 21 13:50:52 CEST 2001 i686 unknown
# insmod binfmt_misc
Using /lib/modules/2.4.12-ac3/kernel/fs/binfmt_misc.o
# echo ':Java:M::\xca\xfe\xba\xbe::/usr/local/bin/javawrapper:'
>/proc/sys/fs/binfmt_misc/register
bash: /proc/sys/fs/binfmt_misc/register: No such file or directory
# lsmod
Module                  Size  Used by
binfmt_misc             5680   1
#rmmod binfmt_misc
binfmt_misc: Device or resource busy                # ?????

Very high C. But this don't work for me.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Albert Bartoszko wrote:

> Linux xxxx 2.4.12-ac3 #1 Sun Oct 21 13:50:52 CEST 2001 i686 unknown
> # insmod binfmt_misc
> Using /lib/modules/2.4.12-ac3/kernel/fs/binfmt_misc.o
> # echo ':Java:M::\xca\xfe\xba\xbe::/usr/local/bin/javawrapper:'
> >/proc/sys/fs/binfmt_misc/register
> bash: /proc/sys/fs/binfmt_misc/register: No such file or directory
> # lsmod
> Module                  Size  Used by
> binfmt_misc             5680   1
> #rmmod binfmt_misc
> binfmt_misc: Device or resource busy                # ?????
> 
> Very high C. But this don't work for me.

Check that your modules.conf contains

post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
pre-remove binfmt_misc umount /proc/sys/binfmt_misc

That should've been there for quite a while, actually.  Keith?

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 02:47:39 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>Check that your modules.conf contains
>
>post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
>pre-remove binfmt_misc umount /proc/sys/binfmt_misc
>
>That should've been there for quite a while, actually.  Keith?

It is not hard wired in the standard modutils, because there is no way
of overriding it.  If the kernel changes the way that binfmt_misc is
handled then users would be stuffed.

RedHat hard code binfmt_misc into their version of modutils but I won't
take the patch, users have to edit modules.conf themselves.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Keith Owens wrote:

> On Mon, 22 Oct 2001 02:47:39 -0400 (EDT), 
> Alexander Viro <viro@math.psu.edu> wrote:
> >Check that your modules.conf contains
> >
> >post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
> >pre-remove binfmt_misc umount /proc/sys/binfmt_misc
> >
> >That should've been there for quite a while, actually.  Keith?
> 
> It is not hard wired in the standard modutils, because there is no way
> of overriding it.

???
Elaborate, please.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 04:05:54 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>On Mon, 22 Oct 2001, Keith Owens wrote:
>> On Mon, 22 Oct 2001 02:47:39 -0400 (EDT), 
>> Alexander Viro <viro@math.psu.edu> wrote:
>> >post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
>> >pre-remove binfmt_misc umount /proc/sys/binfmt_misc
>> 
>> It is not hard wired in the standard modutils, because there is no way
>> of overriding it.
>
>???
>Elaborate, please.

When the post-install and pre-remove entries for module binfmt_misc are
hard coded into modprobe, there is no syntax in modules.conf to prevent
modprobe from always issuing those commands.  The next time somebody
decides that binfmt_misc needs different commands, everybody using the
old modutils on the new kernel will break.  I don't want the hassle,
put it in modules.conf where it can easily be changed.

If I can get an iron clad guarantee that binfmt_misc will never, ever
change again then I might consider hard coding the entries in modprobe.
BTW, I will need a signature in blood that says I can kill you if
binfmt_misc is ever changed :).

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Keith Owens wrote:

> When the post-install and pre-remove entries for module binfmt_misc are
> hard coded into modprobe, there is no syntax in modules.conf to prevent
> modprobe from always issuing those commands.  The next time somebody
> decides that binfmt_misc needs different commands, everybody using the
> old modutils on the new kernel will break.  I don't want the hassle,
> put it in modules.conf where it can easily be changed.
> 
> If I can get an iron clad guarantee that binfmt_misc will never, ever
> change again then I might consider hard coding the entries in modprobe.
> BTW, I will need a signature in blood that says I can kill you if
> binfmt_misc is ever changed :).

Wait a second.  Who says anything about hardcoding that into modprobe?
There is such thing as skeleton stuff for modules.conf, right?

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 04:33:27 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>On Mon, 22 Oct 2001, Keith Owens wrote:
>> If I can get an iron clad guarantee that binfmt_misc will never, ever
>> change again then I might consider hard coding the entries in modprobe.
>> BTW, I will need a signature in blood that says I can kill you if
>> binfmt_misc is ever changed :).
>
>Wait a second.  Who says anything about hardcoding that into modprobe?
>There is such thing as skeleton stuff for modules.conf, right?

Same thing.  The preset entries in modutils util/alias.h are added to
whatever the user has in modules.conf.  In some cases the preset
entries cannot be removed, they are cumulative so the hard coded entry
cannot be removed.

The preset entries already causes problems, why should modutils insist
on options sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330?

>Erm... Keith, I might be misreading the source, but... Shouldn't the
>information like "block major $FOO is in module $BAR" live in
>/lib/modules/*/* ?

Historically the mapping of device majors to module or binary format
type to module was coded into modutils, via util/alias.h.  That was a
mistake, it should have used the same technique as pci, isapnp, parport
etc., each module has a table that defines what it handles and modutils
extracts the data directly from the modules.  Developers have changed
the names of their modules and now we have hard coded module names in
modutils that do not match the names used by some kernels.  Hindsight
is wonderful!

In modutils 2.5 I will get rid of all the hard coded entries in
util/alias.h.  Instead each module will define what it supports,
including any special commands to be run when the module is loaded or
unloaded.  Much easier for everyone and far more flexible.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Keith Owens wrote:

> >Erm... Keith, I might be misreading the source, but... Shouldn't the
> >information like "block major $FOO is in module $BAR" live in
> >/lib/modules/*/* ?
> 
> Historically the mapping of device majors to module or binary format
> type to module was coded into modutils, via util/alias.h.  That was a
> mistake, it should have used the same technique as pci, isapnp, parport
> etc., each module has a table that defines what it handles and modutils
> extracts the data directly from the modules.  Developers have changed
> the names of their modules and now we have hard coded module names in
> modutils that do not match the names used by some kernels.  Hindsight
> is wonderful!
> 
> In modutils 2.5 I will get rid of all the hard coded entries in
> util/alias.h.  Instead each module will define what it supports,
> including any special commands to be run when the module is loaded or
> unloaded.  Much easier for everyone and far more flexible.

Heh.  OK, so you've stopped me in the middle of writing RFC that proposes
addition of
MODULE_CONF(string)
that would put that string into separate section and making modules_install
dump these sections, feed them through s/_NAME_/`basename $module`/ and
cat them into defaults file that would go into $INSTALL_MOD_PATH.
MODULES_BLKDEV(), MODULE_LDISC(), etc. would be trivial wrappers around that.

Looks like the thing you mentioned would make quite a few people happy.
Might be worth doing in 2.4...

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

While we are at it, that would also fix the idiocy with "v7 and sysvfs live
in the same module, need to edit modules.conf to make mount -t v7 ... work".
I can easily think of many other examples of that sort.  Hell, after a
look at /etc/modules.conf on a Debian box...  And yes, stuff with default
options for soundcards... _ouch_

Is there any chance to get that done in 2.4?  Removal of defaults from
modprobe binary is a different story, but at least getting rid of
temptation to add new ones would be a Nice Thing(tm).  Adding relevant
stuff on the kernel side wouldn't break anything and could be tested
gradually...

I'm more than willing to help with that; if you start doing something
of that kind in 2.4 - count me in.  AFAICS it can be done without
breaking compatibility and it's long overdue.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 05:34:43 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>On Mon, 22 Oct 2001, Keith Owens wrote:
>> In modutils 2.5 I will get rid of all the hard coded entries in
>> util/alias.h.  Instead each module will define what it supports,
>> including any special commands to be run when the module is loaded or
>> unloaded.  Much easier for everyone and far more flexible.
>
>Heh.  OK, so you've stopped me in the middle of writing RFC that proposes
>addition of
>MODULE_CONF(string)

Strange, that was exactly what I was planning for 2.5 :).

>that would put that string into separate section and making modules_install

<pedantic>
depmod, not modules_install, depmod is run at other times.
</pedantic>

>dump these sections, feed them through s/_NAME_/`basename $module`/ and

kbuild 2.5 does -DKBUILD_OBJECT=module_name for all objects linked into
a module.  KBUILD_OBJECT defines the overall module, not the individual
files that make up the module.  We have the technology!

>cat them into defaults file that would go into $INSTALL_MOD_PATH.

Just another modules.* file, probably modules.dynamic.conf.

BTW, INSTALL_MOD_PATH is dead in kbuild 2.5, it is a configuration
option and is held in .config.

>MODULES_BLKDEV(), MODULE_LDISC(), etc. would be trivial wrappers around that.

Everything is a device and can be handled by the hotplug project.  It
is really a cunning plan by David Brownell and Greg Kroah-Hartman to
own the entire device subsystem ;).

>Looks like the thing you mentioned would make quite a few people happy.
>Might be worth doing in 2.4...

Please, no more 2.4 changes.  Let Linus get 2.4 stable, fork 2.5 so we
can break it on a daily basis then backport to 2.4 when it works.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Keith Owens wrote:

> >MODULES_BLKDEV(), MODULE_LDISC(), etc. would be trivial wrappers around that.
> 
> Everything is a device and can be handled by the hotplug project.  It
> is really a cunning plan by David Brownell and Greg Kroah-Hartman to
> own the entire device subsystem ;).

No-go - we need that for filesystems.  But that's a separate story - if
MODULE_CONF() is there life already becomes much easier.
 
> >Looks like the thing you mentioned would make quite a few people happy.
> >Might be worth doing in 2.4...
> 
> Please, no more 2.4 changes.  Let Linus get 2.4 stable, fork 2.5 so we
> can break it on a daily basis then backport to 2.4 when it works.

I suspect that in this case s/2.5/2.4-ac/ might be a possibility.  Since
we are talking about defaults, nothing is going to break if file simply
doesn't exist.  So teaching modprobe to handle it if it's there would
be a compatible change and would allow testing the kernel side of that
stuff.  Alan?

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 07:33:37 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>I suspect that in this case s/2.5/2.4-ac/ might be a possibility.  Since
>we are talking about defaults, nothing is going to break if file simply
>doesn't exist.  So teaching modprobe to handle it if it's there would
>be a compatible change and would allow testing the kernel side of that
>stuff.  Alan?

Do you really want modules exhibiting different behaviour in Linus and
-ac kernels?  And have that behaviour depending on which version of
modutils the user installed?  Not in 2.4, modutils strives for
stability in production kernels, it is an important interface between
the kernel and user space.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Keith Owens wrote:

> Please, no more 2.4 changes.  Let Linus get 2.4 stable, fork 2.5 so we
> can break it on a daily basis then backport to 2.4 when it works.

and

> -ac kernels?  And have that behaviour depending on which version of
> modutils the user installed?  Not in 2.4, modutils strives for
> stability in production kernels, it is an important interface between
> the kernel and user space.
 
Correct me if I'm wrong, but two quotes above seem to contradict each other
- AFAICS arguments in the latter apply to backporting...

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Keith Owens]

On Mon, 22 Oct 2001 08:15:45 -0400 (EDT), 
Alexander Viro <viro@math.psu.edu> wrote:
>On Mon, 22 Oct 2001, Keith Owens wrote:
>
>> Please, no more 2.4 changes.  Let Linus get 2.4 stable, fork 2.5 so we
>> can break it on a daily basis then backport to 2.4 when it works.
>
>and
>
>> -ac kernels?  And have that behaviour depending on which version of
>> modutils the user installed?  Not in 2.4, modutils strives for
>> stability in production kernels, it is an important interface between
>> the kernel and user space.
> 
>Correct me if I'm wrong, but two quotes above seem to contradict each other
>- AFAICS arguments in the latter apply to backporting...

I left out a phrase.  "backport to 2.4 when it works and does not
affect 2.4 compatibility".  That is a given on modutils, I won't
consider anything that breaks modutils compatibility on any kernel from
2.4 right down to 2.0.  modutils 2.5 can shatter into tiny pieces, not
a problem.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[bill davidsen]

In article <24947.1003742395@ocs3.intra.ocs.com.au> kaos@ocs.com.au wrote:

| Historically the mapping of device majors to module or binary format
| type to module was coded into modutils, via util/alias.h.  That was a
| mistake, it should have used the same technique as pci, isapnp, parport
| etc., each module has a table that defines what it handles and modutils
| extracts the data directly from the modules.  Developers have changed
| the names of their modules and now we have hard coded module names in
| modutils that do not match the names used by some kernels.  Hindsight
| is wonderful!

  Not to mention the recent surge of renaming the parameters of modules
for no obvious reason... The number of conditionals in modules.conf is
getting pretty large for people who need to run multiple kernels until
the release of one which fixes all the bugs.

| In modutils 2.5 I will get rid of all the hard coded entries in
| util/alias.h.  Instead each module will define what it supports,
| including any special commands to be run when the module is loaded or
| unloaded.  Much easier for everyone and far more flexible.

  I'm not sure about flexible, does it matter where the parameters or
commands are built-in as long as the admin has to change source code
instead of config files to change it? It just seems like a really poor
approach to what has been very flexible.

-- 
bill davidsen <davidsen@tmr.com>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[bill davidsen]

In article <23837.1003738907@kao2.melbourne.sgi.com> you write:

| When the post-install and pre-remove entries for module binfmt_misc are
| hard coded into modprobe, there is no syntax in modules.conf to prevent
| modprobe from always issuing those commands.  The next time somebody
| decides that binfmt_misc needs different commands, everybody using the
| old modutils on the new kernel will break.  I don't want the hassle,
| put it in modules.conf where it can easily be changed.

  Thank you. Configuration things should be in configuration files!

  I hope people will continue to resist changes which make things easy
for casual users while making them very difficult for more technically
inclined people. Having to get source and recompile to disable a feature
is hardly reasonable.

-- 
bill davidsen <davidsen@tmr.com>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Andrew Morton]

Alexander Viro wrote:
> 
> ...
> Check that your modules.conf contains
> 
> post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
> pre-remove binfmt_misc umount /proc/sys/binfmt_misc
> 

Why is it necessary that the new binfmt_misc create its own
filesystem type, when all it seems to need is a couple of
/proc entries?

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alexander Viro]

On Mon, 22 Oct 2001, Andrew Morton wrote:

> Why is it necessary that the new binfmt_misc create its own
> filesystem type, when all it seems to need is a couple of
> /proc entries?

If it was so nice...  It needs to create and remove them upon
write(2).  And doing that correctly via procfs is _not_ pretty.
The damn thing is very bad at doing dynamic contents and when
mixed with API of that weirdness...

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Albert Bartoszko]

> ...............
> Check that your modules.conf contains
>
> post-install binfmt_misc mount -t binfmt_misc none /proc/sys/binfmt_misc
> pre-remove binfmt_misc umount /proc/sys/binfmt_misc
>
Yes, now contains, and mount, umount and binfmt work propely.
This should be documented in sources

xx:/tmp# egrep -Hr "mount[[:space:]]+-t[[:space:]]+binfmt_misc"
/usr/src/linux
xx:/tmp#

But I still  can't unload module (unmounted):
#rmmod binfmt_misc
binfmt_misc: Device or resource busy

Re: [PATCH] binfmt_misc.c, kernel-2.4.12

[Alan Cox]

> I find bug in  binfmt_misc.c from kernel 2.4.12 source. The read() syscal
> return bad value, causes some application SIGSEGV.

This has been fixed in the -ac tree since early 2.4, but Linus didnt want
the fs based binfmt changes