Patchwork BUG: physmap modprobe & rmmod

login
register
mail settings
Submitter hartleys
Date April 2, 2010, 10:41 p.m.
Message ID <0D753D10438DA54287A00B0270842697636A7E9D2C@AUSP01VMBX24.collaborationhost.net>
Download mbox | patch
Permalink /patch/49328/
State New
Headers show

Comments

hartleys - April 2, 2010, 10:41 p.m.
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@visionengravers.com>

---

Patch

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;