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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 8 Sep 2015 21:36:01 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
	Russel King <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 15/16] mtd: mtdcore: fix initcall level

Am 04.09.2015 um 06:00 schrieb Alexander Holler:
> Am 02.09.2015 um 07:34 schrieb Alexander Holler:
>> Am 01.09.2015 um 23:19 schrieb Brian Norris:
>>> Hi Alexander,
>>>
>>> No judgment here for the rest of this series, but for this patch:
>>>
>>> On Wed, Aug 26, 2015 at 02:28:27PM +0200, Alexander Holler wrote:
>>>> The mtd-core has to be initialized before other dependent mtd-drivers,
>>>> otherwise a crash might occur.
>>>>
>>>> Currently mtd_init() is called in the initcall-level device, which is
>>>> the
>>>> same level where most mtd-drivers will end up. By luck this seemed to
>>>> have
>>>> been called most of the time before other mtd-drivers without having
>>>> been
>>>> explicitly enforced.
>>>
>>> I can't really speak for the original authors, but it does not appear to
>>> be entirely "by luck." Link order was one of the de facto ways to get
>>> this ordering (though it's not really a great one), and mtdcore was
>>> always linked first within the drivers/mtd/ directory structure.
>>>
>>> But that's just background, I think this is worth fixing anyway. It
>>> could, for instance, become a problem if drivers are located outside
>>> drivers/mtd/; I see random board files in arch/ that register with MTD,
>>> and I'm actually not sure how they have never tripped on this.

As I've just had a look at my patches in order to clean up the patch for 
parallel initialization (to post it here too):

drivers/mtd/ofparts.c has the same problem. In order to let the 
NAND-driver see the partitions defined in the DT I had to move this into 
another initcall level (fs sync) too.

Regards,

Alexander Holler
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ