lkml.org 
[lkml]   [2008]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: physmap and "request_module: runaway loop modprobe net-pf-1"
On Wed, 12 Mar 2008 01:06:53 -0600 "Gordon Farquharson" <gordonfarquharson@gmail.com> wrote:

> Hi Andrew
>
> On Tue, Mar 11, 2008 at 11:59 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Tue, 11 Mar 2008 23:35:28 -0600 "Gordon Farquharson" <gordonfarquharson@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

err, yes, scrub that.

> > 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,

There's a good chance that there will be no response.

> 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
>

Just send the patch, please. Please retain you original analysis in its
covering description.



\
 
 \ /
  Last update: 2008-03-12 08:23    [W:0.096 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site