LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [BUG] re-modprobe a nand controller driver module will cause system crash.
@ 2008-10-16 10:56 Bryan Wu
  2008-10-22  3:24 ` Bryan Wu
  0 siblings, 1 reply; 4+ messages in thread
From: Bryan Wu @ 2008-10-16 10:56 UTC (permalink / raw)
  To: dwmw2, linux-mtd, LKML

Hi folks,

These days I found a subtle bug which should be related with mtdcore layers.
The detailed story is located at
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=4463.

Briefly speaking,
1) modprobe a nand controller driver to add_mtd_paritition().
2) add_mtd_partition->add_devices->blktrans_notify_add->mtdblock_add_mtd->add_mtd_blktrans_dev
3) in add_mtd_blktrans_dev, alloc_disk will be called to create a new
gendisk structure according to the partition setting.
4) "gd->queue = tr->blkcore_priv->rq;"
    No matter how many partitions (in my test, 2 partitions), there
will be the same number gendisk structures but just 1 queue.
    They all use the same request_queue which is created in
register_mtd_blktrans.
5) mtdblockd kthread handles this request_queue for mtdblock layer.
6) There is one backing_dev_info structure member (not pointer) in
request_queue. so for several mtd partitions (serveral gendisks) there
is only one bdi structure instance.
7) So the problem is in add_disk(),
    bdi_register_dev(bdi, MKDEV(disk->major, disk->first_minor));
    For 1st partition mtdblock0, it will create /sys/class/bdi/31:0
and register information in bdi structure instance.
    Then for 2nd partition mtdblock1, because the bdi structure
instance is the same as the 1st partition, it will overwrite bdi
structure and create /sys/class/bdi/31:1.
    So the bdi info of 1st partition are totally lost.
8) When we rmmod the nand controller driver, del_mtd_partition will
only remove /sys/class/bdi/31:1 but left 1st partition
/sys/class/bdi/31:0 there.
9) modprobe again will let the bug show up.

I found this bug does not relate with my nand flash controller driver
and it should be fixed in mtdblock layer.
And if we just add only one partition, there is no such bug at all. I
tried to solve this bug, but it related with
mtdblock/mtd_blktrans/block/bdi. It is diffcult for me to find a way
to satisfy all the parts with minimal changes.

IMHO, can we just simply remove the bdi_register_dev (in add_disk) and
bdi_unregister_dev (in unlink_disk)?

P.S. I also found this bug in latest 2.6.27 kernel mainline.

Thanks
-Bryan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] re-modprobe a nand controller driver module will cause system crash.
  2008-10-16 10:56 [BUG] re-modprobe a nand controller driver module will cause system crash Bryan Wu
@ 2008-10-22  3:24 ` Bryan Wu
  2008-10-22 14:59   ` Mike Frysinger
  0 siblings, 1 reply; 4+ messages in thread
From: Bryan Wu @ 2008-10-22  3:24 UTC (permalink / raw)
  To: dwmw2, linux-mtd, LKML

Hi folks,

Did anyone meet this issue before?

-Bryan

On Thu, Oct 16, 2008 at 6:56 PM, Bryan Wu <cooloney@kernel.org> wrote:
> Hi folks,
>
> These days I found a subtle bug which should be related with mtdcore layers.
> The detailed story is located at
> https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=4463.
>
> Briefly speaking,
> 1) modprobe a nand controller driver to add_mtd_paritition().
> 2) add_mtd_partition->add_devices->blktrans_notify_add->mtdblock_add_mtd->add_mtd_blktrans_dev
> 3) in add_mtd_blktrans_dev, alloc_disk will be called to create a new
> gendisk structure according to the partition setting.
> 4) "gd->queue = tr->blkcore_priv->rq;"
>    No matter how many partitions (in my test, 2 partitions), there
> will be the same number gendisk structures but just 1 queue.
>    They all use the same request_queue which is created in
> register_mtd_blktrans.
> 5) mtdblockd kthread handles this request_queue for mtdblock layer.
> 6) There is one backing_dev_info structure member (not pointer) in
> request_queue. so for several mtd partitions (serveral gendisks) there
> is only one bdi structure instance.
> 7) So the problem is in add_disk(),
>    bdi_register_dev(bdi, MKDEV(disk->major, disk->first_minor));
>    For 1st partition mtdblock0, it will create /sys/class/bdi/31:0
> and register information in bdi structure instance.
>    Then for 2nd partition mtdblock1, because the bdi structure
> instance is the same as the 1st partition, it will overwrite bdi
> structure and create /sys/class/bdi/31:1.
>    So the bdi info of 1st partition are totally lost.
> 8) When we rmmod the nand controller driver, del_mtd_partition will
> only remove /sys/class/bdi/31:1 but left 1st partition
> /sys/class/bdi/31:0 there.
> 9) modprobe again will let the bug show up.
>
> I found this bug does not relate with my nand flash controller driver
> and it should be fixed in mtdblock layer.
> And if we just add only one partition, there is no such bug at all. I
> tried to solve this bug, but it related with
> mtdblock/mtd_blktrans/block/bdi. It is diffcult for me to find a way
> to satisfy all the parts with minimal changes.
>
> IMHO, can we just simply remove the bdi_register_dev (in add_disk) and
> bdi_unregister_dev (in unlink_disk)?
>
> P.S. I also found this bug in latest 2.6.27 kernel mainline.
>
> Thanks
> -Bryan
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] re-modprobe a nand controller driver module will cause system crash.
  2008-10-22  3:24 ` Bryan Wu
@ 2008-10-22 14:59   ` Mike Frysinger
  2008-10-23  1:06     ` Bryan Wu
  0 siblings, 1 reply; 4+ messages in thread
From: Mike Frysinger @ 2008-10-22 14:59 UTC (permalink / raw)
  To: Bryan Wu; +Cc: dwmw2, linux-mtd, LKML

On Tue, Oct 21, 2008 at 23:24, Bryan Wu wrote:
> Did anyone meet this issue before?

actually i think we can see the same issue with the m25p80 driver ?
if i build it as a module and load/unload it, it crashes with same
name errors ...

root:/> rmmod m25p80
root:/> modprobe m25p80
m25p80 spi0.2: w25x10 (128 Kbytes)
Creating 3 MTD partitions on "m25p80":
0x00000000-0x00040000 : "bootloader(spi)"
mtd: partition "bootloader(spi)" extends beyond the end of device
"m25p80" -- size truncated to 0x20000
kobject_add_internal failed for 31:0 with -EEXIST, don't try to
register things with the same name in the same directory.
<crash message>
-mike

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] re-modprobe a nand controller driver module will cause system crash.
  2008-10-22 14:59   ` Mike Frysinger
@ 2008-10-23  1:06     ` Bryan Wu
  0 siblings, 0 replies; 4+ messages in thread
From: Bryan Wu @ 2008-10-23  1:06 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: dwmw2, linux-mtd, LKML

On Wed, Oct 22, 2008 at 10:59 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Tue, Oct 21, 2008 at 23:24, Bryan Wu wrote:
>> Did anyone meet this issue before?
>
> actually i think we can see the same issue with the m25p80 driver ?
> if i build it as a module and load/unload it, it crashes with same
> name errors ...
>

Right, this is a common bug for mtd core.

-Bryan

> root:/> rmmod m25p80
> root:/> modprobe m25p80
> m25p80 spi0.2: w25x10 (128 Kbytes)
> Creating 3 MTD partitions on "m25p80":
> 0x00000000-0x00040000 : "bootloader(spi)"
> mtd: partition "bootloader(spi)" extends beyond the end of device
> "m25p80" -- size truncated to 0x20000
> kobject_add_internal failed for 31:0 with -EEXIST, don't try to
> register things with the same name in the same directory.
> <crash message>
> -mike
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-10-23  1:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-16 10:56 [BUG] re-modprobe a nand controller driver module will cause system crash Bryan Wu
2008-10-22  3:24 ` Bryan Wu
2008-10-22 14:59   ` Mike Frysinger
2008-10-23  1:06     ` Bryan Wu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).