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] [day] [month] [year] [list]
Message-ID: <0D753D10438DA54287A00B0270842697636A7E9D2C@AUSP01VMBX24.collaborationhost.net>
Date:	Fri, 2 Apr 2010 17:41:25 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>,
	lkml <linux-kernel@...r.kernel.org>
CC:	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: RE: BUG: physmap modprobe & rmmod

On Friday, April 02, 2010 3:16 PM, H Hartley Sweeten wrote:
> On Friday, April 02, 2010 2:47 PM, Randy Dunlap wrote:
>>> 2.6.34-rc2 kernel:
>>> 
>>> Boot up on a common PC, then: modprobe physmap ; rmmod physmap
>>> and bang.
>
> [snip]
>
>> This is with close to an allmodconfig on x86_64, including:
>> 
>> CONFIG_MTD_PHYSMAP=m
>> CONFIG_MTD_PHYSMAP_COMPAT=y
>> CONFIG_MTD_PHYSMAP_START=0x8000000
>> CONFIG_MTD_PHYSMAP_LEN=0
>> CONFIG_MTD_PHYSMAP_BANKWIDTH=2
>
> That's probably the cause of the BUG.
>
> If your not run-time calling physmap_configure(), your resource will
> be created as:
>
> static struct physmap_flash_data physmap_flash_data = {
>	.width		= CONFIG_MTD_PHYSMAP_BANKWIDTH,
> };
>
> static struct resource physmap_flash_resource = {
>	.start		= CONFIG_MTD_PHYSMAP_START,
>	.end		= CONFIG_MTD_PHYSMAP_START + CONFIG_MTD_PHYSMAP_LEN - 1,
>	.flags		= IORESOURCE_MEM,
> };
>
> In other words:
>
> static struct physmap_flash_data physmap_flash_data = {
>	.width		= 2,
> };
>
> static struct resource physmap_flash_resource = {
>	.start		= 0x8000000,
>	.end		= 0x8000000 + 0 - 1,
>	.flags		= IORESOURCE_MEM,
> };

I traced this down to kernel/resource.c.  When __request_resource
is finally called, because of the platform_device_register, it ends
up returning a conflict due to:

	resource_size_t start = new->start;
	resource_size_t end = new->end;
	struct resource *tmp, **p;

	if (end < start)
		return root;

This ends up causing an -EBUSY error code.  The patch below should
be correct to fix this.

I changed the commit message a bit.

---

mtd/maps/physmap: catch failure to register MTD_PHYSMAP_COMPAT device

If the default Kconfig values are used with MTD_PHYSMAP_COMPAT you end
up with a resource where end < start.  This causes __request_resource to
return a conflict which then returns an -EBUSY error code.  The current
physmap.c code just assumes that the platfom_device_register will always
succeed.

Catch this failure during the physmap_init and propogate the error.

Signed-off-by: H Hartley Sweeten <hsweeten@...ionengravers.com>

---

diff --git a/drivers/mtd/maps/physmap.c b/drivers/mtd/maps/physmap.c
index d9603f7..426461a 100644
--- a/drivers/mtd/maps/physmap.c
+++ b/drivers/mtd/maps/physmap.c
@@ -264,8 +264,11 @@ static int __init physmap_init(void)
 
 	err = platform_driver_register(&physmap_flash_driver);
 #ifdef CONFIG_MTD_PHYSMAP_COMPAT
-	if (err == 0)
-		platform_device_register(&physmap_flash);
+	if (err == 0) {
+		err = platform_device_register(&physmap_flash);
+		if (err)
+			platform_driver_unregister(&physmap_flash_driver);
+	}
 #endif
 
 	return err;

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
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