From: Andrew Morton <akpm@linux-foundation.org>
To: "Gordon Farquharson" <gordonfarquharson@gmail.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: physmap and "request_module: runaway loop modprobe net-pf-1"
Date: Wed, 12 Mar 2008 00:19:18 -0700 [thread overview]
Message-ID: <20080312001918.78b6f7bd.akpm@linux-foundation.org> (raw)
In-Reply-To: <97a0a9ac0803120006k30a0ef7dq7b67518bca384b03@mail.gmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Gordon Farquharson" <gordonfarquharson@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: physmap and "request_module: runaway loop modprobe net-pf-1"
Date: Wed, 12 Mar 2008 00:19:18 -0700 [thread overview]
Message-ID: <20080312001918.78b6f7bd.akpm@linux-foundation.org> (raw)
In-Reply-To: <97a0a9ac0803120006k30a0ef7dq7b67518bca384b03@mail.gmail.com>
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.
next prev parent reply other threads:[~2008-03-12 7:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 5:35 physmap and "request_module: runaway loop modprobe net-pf-1" Gordon Farquharson
2008-03-12 5:59 ` Andrew Morton
2008-03-12 5:59 ` Andrew Morton
2008-03-12 7:06 ` Gordon Farquharson
2008-03-12 7:06 ` Gordon Farquharson
2008-03-12 7:19 ` Andrew Morton [this message]
2008-03-12 7:19 ` Andrew Morton
2008-03-12 7:36 ` David Woodhouse
2008-03-12 7:36 ` David Woodhouse
2008-04-22 12:37 ` David Woodhouse
2008-04-22 12:37 ` David Woodhouse
2008-04-24 4:01 ` Gordon Farquharson
2008-04-24 4:01 ` Gordon Farquharson
2008-04-24 5:49 ` David Woodhouse
2008-04-24 5:49 ` David Woodhouse
2008-04-24 6:10 ` David Miller
2008-04-24 6:10 ` David Miller
2008-04-24 7:16 ` David Woodhouse
2008-04-24 7:16 ` David Woodhouse
2008-04-24 7:20 ` David Miller
2008-04-24 7:20 ` David Miller
2008-04-24 7:24 ` David Woodhouse
2008-04-24 7:24 ` David Woodhouse
2008-04-24 7:58 ` David Miller
2008-04-24 7:58 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080312001918.78b6f7bd.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=gordonfarquharson@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.