| Message ID | 20210613113035.2329421-1-chengzhihao1@huawei.com |
|---|---|
| Headers | show |
| Series | Fix deadlock in ftl formating on mtd | expand |
Hi Zhihao, Zhihao Cheng <chengzhihao1@huawei.com> wrote on Sun, 13 Jun 2021 19:30:29 +0800: > There is an AA-deadlock problem while formating mtd device to generate > a ftl device. Fix it by reverting "mtd: allow to unload the mtdtrans > module if its block devices aren't open" recommended in [1]. > > [<0>] blktrans_open+0x47/0x340 LOCK(mtd_table_mutex) > [<0>] __blkdev_get+0x5b/0x3e0 > [<0>] blkdev_get_by_dev+0x18f/0x370 > [<0>] __device_add_disk+0x2db/0x700 > [<0>] device_add_disk+0x17/0x20 > [<0>] add_mtd_blktrans_dev+0x39e/0x6d0 > [<0>] ftl_add_mtd+0x792/0x908 [ftl] > [<0>] register_mtd_blktrans+0xfb/0x170 LOCK(mtd_table_mutex) > [<0>] ftl_tr_init+0x18/0x1000 [ftl] > [<0>] do_one_initcall+0x71/0x330 > [<0>] do_init_module+0xa6/0x350 > > [1] http://lists.infradead.org/pipermail/linux-mtd/2017-March/072899.html > > Zhihao Cheng (6): > Revert "mtd: blkdevs: fix potential deadlock + lockdep warnings" > Revert "mtd: fix: avoid race condition when accessing mtd->usecount" > Revert "mtd: mtd_blkdevs: don't increase 'open' count on error path" > Revert "mtd: mtd_blkdevs: fix error path in blktrans_open" > Revert "mtd: Remove redundant mutex from mtd_blkdevs.c" > Revert "mtd: allow to unload the mtdtrans module if its block devices > aren't open" I understand that some fixes need to revert a couple of patches, but isn't reverting 6 commits from the v2.6.32 kernel a bit odd for that? At least, can you justify this choice? Are all these commits useless and buggy? > > drivers/mtd/mtd_blkdevs.c | 77 +++++++++++++++------------------------ > 1 file changed, 30 insertions(+), 47 deletions(-) > Thanks, Miquèl
在 2021/6/13 23:12, Miquel Raynal 写道: > Hi Zhihao, > > Zhihao Cheng <chengzhihao1@huawei.com> wrote on Sun, 13 Jun 2021 > 19:30:29 +0800: > >> There is an AA-deadlock problem while formating mtd device to generate >> a ftl device. Fix it by reverting "mtd: allow to unload the mtdtrans >> module if its block devices aren't open" recommended in [1]. >> > I understand that some fixes need to revert a couple of patches, but > isn't reverting 6 commits from the v2.6.32 kernel a bit odd for that? > At least, can you justify this choice? Are all these commits useless > and buggy? > Hi Miquel, This series of revert patches came from history commits which related with "mtd: allow to unload the mtdtrans module if its block devices aren't open". I admin it's a weird method and let's forget it. After some local tests, I think we'd better reserve "mtd: allow to unload the mtdtrans module if its block devices aren't open" to support removing mtdblock module if no one takes it. But we may move get|put mtd_device into add|del_mtd_blktrans to solve deadlock problem, maybe we don't have to get_mtd_device each time open mtd block device in blktrans_open if we have called get_mtd_device() in add_mtd_blktrans_dev(). See v2 "mtd: mtd_blkdevs: Get|Put mtd_device in add|del_mtd_blktrans". > Thanks, > Miquèl > .
在 2021/6/13 23:12, Miquel Raynal 写道: > Hi Zhihao, > > Zhihao Cheng <chengzhihao1@huawei.com> wrote on Sun, 13 Jun 2021 > 19:30:29 +0800: > > > I understand that some fixes need to revert a couple of patches, but > isn't reverting 6 commits from the v2.6.32 kernel a bit odd for that? > At least, can you justify this choice? Are all these commits useless > and buggy? Hi Miquel, This series of revert patches came from history commits which related with "mtd: allow to unload the mtdtrans module if its block devices aren't open". I admin it's a weird method and let's forget it. After some local tests, I think we'd better reserve "mtd: allow to unload the mtdtrans module if its block devices aren't open" to support removing mtdblock module if no one takes it. But we may move get|put mtd_device into add|del_mtd_blktrans to solve deadlock problem, maybe we don't have to get_mtd_device each time open mtd block device in blktrans_open if we have called get_mtd_device() in add_mtd_blktrans_dev(). See v2 "mtd: mtd_blkdevs: Get|Put mtd_device in add|del_mtd_blktrans". >> > > Thanks, > Miquèl > . >
There is an AA-deadlock problem while formating mtd device to generate a ftl device. Fix it by reverting "mtd: allow to unload the mtdtrans module if its block devices aren't open" recommended in [1]. [<0>] blktrans_open+0x47/0x340 LOCK(mtd_table_mutex) [<0>] __blkdev_get+0x5b/0x3e0 [<0>] blkdev_get_by_dev+0x18f/0x370 [<0>] __device_add_disk+0x2db/0x700 [<0>] device_add_disk+0x17/0x20 [<0>] add_mtd_blktrans_dev+0x39e/0x6d0 [<0>] ftl_add_mtd+0x792/0x908 [ftl] [<0>] register_mtd_blktrans+0xfb/0x170 LOCK(mtd_table_mutex) [<0>] ftl_tr_init+0x18/0x1000 [ftl] [<0>] do_one_initcall+0x71/0x330 [<0>] do_init_module+0xa6/0x350 [1] http://lists.infradead.org/pipermail/linux-mtd/2017-March/072899.html Zhihao Cheng (6): Revert "mtd: blkdevs: fix potential deadlock + lockdep warnings" Revert "mtd: fix: avoid race condition when accessing mtd->usecount" Revert "mtd: mtd_blkdevs: don't increase 'open' count on error path" Revert "mtd: mtd_blkdevs: fix error path in blktrans_open" Revert "mtd: Remove redundant mutex from mtd_blkdevs.c" Revert "mtd: allow to unload the mtdtrans module if its block devices aren't open" drivers/mtd/mtd_blkdevs.c | 77 +++++++++++++++------------------------ 1 file changed, 30 insertions(+), 47 deletions(-)