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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080312001918.78b6f7bd.akpm@linux-foundation.org>
Date:	Wed, 12 Mar 2008 00:19:18 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Gordon Farquharson" <gordonfarquharson@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: physmap and "request_module: runaway loop modprobe net-pf-1"

On Wed, 12 Mar 2008 01:06:53 -0600 "Gordon Farquharson" <gordonfarquharson@...il.com> wrote:

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/