Re: physmap and "request_module: runaway loop modprobe net-pf-1"

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Woodhouse]

On Tue, 2008-03-11 at 22:59 -0700, Andrew Morton wrote:
> Now, af_unix_init() uses module_init(), which is really __initcall(), which
> is really device_initcall() (ug, don't ask).

... which is really __define_initcall("6", ...);.

> So you can do what you're sugesting here by locating the caller/callers of
> parse_mtd_partitions() and marking them late_initcall().

Better still, just initialise af_unix earlier so that it's there before
any normal drivers which happen to call request_module(). Since core
network stuff is initialised with subsys_initcall() which is really
__define_initcall("4", ...), we can initialise af_unix with
fs_initcall() which is really __define_initcall("5", ...).


---
[AF_UNIX] Initialise UNIX sockets before general device initcalls

When drivers call request_module(), it tries to do something with UNIX
sockets and triggers a 'runaway loop modprobe net-pf-1' warning. Avoid
this by initialising AF_UNIX support earlier.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

--- linux-2.6.24.ppc/net/unix/af_unix.c~	2008-04-13 13:38:25.000000000 +0100
+++ linux-2.6.24.ppc/net/unix/af_unix.c	2008-04-22 13:01:45.000000000 +0100
@@ -2193,7 +2193,11 @@ static void __exit af_unix_exit(void)
 	unregister_pernet_subsys(&unix_net_ops);
 }
 
-module_init(af_unix_init);
+/* Earlier than device_initcall() so that other drivers invoking
+   request_module() don't end up in a loop when modprobe tries
+   to use a UNIX socket. But later than subsys_initcall() because
+   we depend on stuff initialised there */
+fs_initcall(af_unix_init);
 module_exit(af_unix_exit);
 
 MODULE_LICENSE("GPL");


-- 
dwmw2

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[Gordon Farquharson]

Hi David

On Tue, Apr 22, 2008 at 6:37 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2008-03-11 at 22:59 -0700, Andrew Morton wrote:
>
> > Now, af_unix_init() uses module_init(), which is really __initcall(), which
>  > is really device_initcall() (ug, don't ask).
>
>  ... which is really __define_initcall("6", ...);.
>
>
>  > So you can do what you're sugesting here by locating the caller/callers of
>  > parse_mtd_partitions() and marking them late_initcall().
>
>  Better still, just initialise af_unix earlier so that it's there before
>  any normal drivers which happen to call request_module(). Since core
>  network stuff is initialised with subsys_initcall() which is really
>  __define_initcall("4", ...), we can initialise af_unix with
>  fs_initcall() which is really __define_initcall("5", ...).

I tested the patch you sent. It fixes the runaway modprobe messages,
but I get a modprobe error (see below) with the Debian kernel I used
to test the patch because modules.dep does not exist in the initramfs
(should it?). In my kernel config, I did not enable
CONFIG_MTD_CMDLINE_PARTS and I set CONFIG_MTD_REDBOOT_PARTS=m but the
redboot module was not included in the initramfs so it could not be
loaded, hence the messages saying that the parsing schemes are not
available.

[    4.790000] physmap platform flash device: 00080000 at f0000000
[    4.800000] Found: ST M29W400DB
[    4.800000] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
[    4.810000] number of JEDEC chips: 1
[    4.810000] cfi_cmdset_0002: Disabling erase-suspend-program due to
code brokenness.
modprobe: FATAL: Could not load
/lib/modules/2.6.25-trunk-iop32x/modules.dep: No such file or
directory

[    4.900000] cmdlinepart partition parsing not available
modprobe: FATAL: Could not load
/lib/modules/2.6.25-trunk-iop32x/modules.dep: No such file or
directory

[    4.970000] RedBoot partition parsing not available

I guess the question is which patch (if either) is more appealing.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Woodhouse]

On Wed, 2008-04-23 at 22:01 -0600, Gordon Farquharson wrote:
> I guess the question is which patch (if either) is more appealing.

I definitely think we should initialise AF_UNIX sockets earlier. At
least request_module() _can_ work then, if you want it to and you set up
userspace accordingly.

I'm also tempted to reduce the proliferation of modules in drivers/mtd
and turn the various partition options into booleans, though. Your
original patch is close, but I don't think it works in the CONFIG_MTD=m
case. I think we need to modify drivers/mtd/Makefile too, along these
lines:

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 4b77335..6137eec 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -7,12 +7,12 @@ obj-$(CONFIG_MTD)             += mtd.o
 mtd-y                          := mtdcore.o mtdsuper.o
 mtd-$(CONFIG_MTD_PARTITIONS)   += mtdpart.o
 
-obj-$(CONFIG_MTD_CONCAT)       += mtdconcat.o
-obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
-obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
-obj-$(CONFIG_MTD_AFS_PARTS)    += afs.o
-obj-$(CONFIG_MTD_AR7_PARTS)    += ar7part.o
-obj-$(CONFIG_MTD_OF_PARTS)      += ofpart.o
+mtd-$(CONFIG_MTD_CONCAT)       += mtdconcat.o
+mtd-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
+mtd-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
+mtd-$(CONFIG_MTD_AFS_PARTS)    += afs.o
+mtd-$(CONFIG_MTD_AR7_PARTS)    += ar7part.o
+mtd-$(CONFIG_MTD_OF_PARTS)      += ofpart.o
 
 # 'Users' - code which presents functionality to userspace.
 obj-$(CONFIG_MTD_CHAR)         += mtdchar.o


I'll play with it.

-- 
dwmw2

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 24 Apr 2008 06:49:03 +0100

> On Wed, 2008-04-23 at 22:01 -0600, Gordon Farquharson wrote:
> > I guess the question is which patch (if either) is more appealing.
> 
> I definitely think we should initialise AF_UNIX sockets earlier. At
> least request_module() _can_ work then, if you want it to and you set up
> userspace accordingly.

I'm not so sure, for example, what if AF_UNIX is built modular?

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Woodhouse]

On Wed, 2008-04-23 at 23:10 -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Thu, 24 Apr 2008 06:49:03 +0100
> 
> > On Wed, 2008-04-23 at 22:01 -0600, Gordon Farquharson wrote:
> > > I guess the question is which patch (if either) is more appealing.
> > 
> > I definitely think we should initialise AF_UNIX sockets earlier. At
> > least request_module() _can_ work then, if you want it to and you set up
> > userspace accordingly.
> 
> I'm not so sure, for example, what if AF_UNIX is built modular?

I believe that as long as you include it in your initrd, it'll get
loaded on demand and all will be well. The first request_module() call
will trigger a request_module(af_unix), which will succeed.

-- 
dwmw2

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 24 Apr 2008 08:16:39 +0100

> On Wed, 2008-04-23 at 23:10 -0700, David Miller wrote:
> > From: David Woodhouse <dwmw2@infradead.org>
> > Date: Thu, 24 Apr 2008 06:49:03 +0100
> > 
> > > On Wed, 2008-04-23 at 22:01 -0600, Gordon Farquharson wrote:
> > > > I guess the question is which patch (if either) is more appealing.
> > > 
> > > I definitely think we should initialise AF_UNIX sockets earlier. At
> > > least request_module() _can_ work then, if you want it to and you set up
> > > userspace accordingly.
> > 
> > I'm not so sure, for example, what if AF_UNIX is built modular?
> 
> I believe that as long as you include it in your initrd, it'll get
> loaded on demand and all will be well. The first request_module() call
> will trigger a request_module(af_unix), which will succeed.

But won't the request_module() for AF_UNIX spit out that warning too?

Actually, I think I need a clarification.  It is the modular loader
utility in userspace which is trying to open up AF_UNIX sockets,
right?

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Woodhouse]

On Thu, 2008-04-24 at 00:20 -0700, David Miller wrote:
> But won't the request_module() for AF_UNIX spit out that warning too?

Yes. If you build AF_UNIX as a module, it will. Just once though, before
loading it (assuming it's available).

> Actually, I think I need a clarification.  It is the modular loader
> utility in userspace which is trying to open up AF_UNIX sockets,
> right?

Yes. Or probably libc.

-- 
dwmw2

Re: physmap and "request_module: runaway loop modprobe net-pf-1"

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 24 Apr 2008 08:24:12 +0100

> On Thu, 2008-04-24 at 00:20 -0700, David Miller wrote:
> > But won't the request_module() for AF_UNIX spit out that warning too?
> 
> Yes. If you build AF_UNIX as a module, it will. Just once though, before
> loading it (assuming it's available).
> 
> > Actually, I think I need a clarification.  It is the modular loader
> > utility in userspace which is trying to open up AF_UNIX sockets,
> > right?
> 
> Yes. Or probably libc.

Ok, I'll apply your patch, but really this all feels like a jumble
of hacks to me :-)