linux-kernel - Re: [PATCH 0/6] Fix deadlock in ftl formating on mtd

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: <13b42e51-d176-ad54-e3a1-353284bb2d2e@huawei.com>
Date:   Tue, 15 Jun 2021 17:08:34 +0800
From:   Zhihao Cheng <chengzhihao1@...wei.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
CC:     <richard@....at>, <vigneshr@...com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <yukuai3@...wei.com>
Subject: Re: [PATCH 0/6] Fix deadlock in ftl formating on mtd

在 2021/6/13 23:12, Miquel Raynal 写道:
> Hi Zhihao,
> 
> Zhihao Cheng <chengzhihao1@...wei.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
> .
>