physmap and "request_module: runaway loop modprobe net-pf-1"
Gordon Farquharson
gordonfarquharson at gmail.com
Wed Mar 12 03:06:53 EDT 2008
Hi Andrew
On Tue, Mar 11, 2008 at 11:59 PM, Andrew Morton
<akpm at linux-foundation.org> wrote:
> On Tue, 11 Mar 2008 23:35:28 -0600 "Gordon Farquharson" <gordonfarquharson at gmail.com> wrote:
> > Alternatively, if selecting CONFIG_MTD_PARTITIONS and not selecting
> > both CONFIG_MTD_REDBOOT_PARTS and CONFIG_CMDLINE_PARTS, or selecting
> > CONFIG_MTD_PARTITIONS and not selecting CONFIG_CMDLINE_PARTS and
> > selecting CONFIG_MTD_REDBOOT_PARTS as a module, are valid
> > configurations, it seems that parse_mtd_partitions() must be called
> > only after af_unix_init() has been called. Is this possible?
>
> Probably.
>
> We can specify the order in which these things are called at compile-time.
> See these, from include/linux/init.h:
>
> #define core_initcall(fn) __define_initcall("1",fn,1)
> #define postcore_initcall(fn) __define_initcall("2",fn,2)
> #define arch_initcall(fn) __define_initcall("3",fn,3)
> #define subsys_initcall(fn) __define_initcall("4",fn,4)
> #define fs_initcall(fn) __define_initcall("5",fn,5)
> #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
> #define device_initcall(fn) __define_initcall("6",fn,6)
> #define late_initcall(fn) __define_initcall("7",fn,7)
>
> Now, af_unix_init() uses module_init(), which is really __initcall(), which
> is really device_initcall() (ug, don't ask).
>
> So you can do what you're sugesting here by locating the caller/callers of
> parse_mtd_partitions() and marking them late_initcall().
Thanks very much for the explanation.
It looks like there could be up to 38 distinct callers of
parse_mtd_partitions(), and I expect that one would need to test all
of the various platforms on which these calls occur to ensure that
there were no regressions introduced by the change, so this option
scares me a little.
$ grep parse_mtd_partitions -r * | wc -l
38
> I'd suggest that you make your own decision as to what is the best fix, then
> send a patch. Please cc me on it and I'll make sure that it gets
> appropriately handled. This may take a bit of time, as the MTD patch
> backlog is rather large at present.
I'll see how the MTD guys respond today, and then submit a patch
later. I like option 1, but they may have a good reason for needing to
compile a parser as a module, or they may propose a completely
different solution. Right now, there is only one defconfig that has
CONFIG_REDBOOT_MTD_PARTS=m:
arch/mips/configs/mtx1_defconfig:CONFIG_MTD_REDBOOT_PARTS=m
Thanks very much for the input.
Gordon
--
Gordon Farquharson
GnuPG Key ID: 32D6D676
More information about the linux-mtd
mailing list