From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Richard Weinberger <richard@nod.at>
Cc: Yu Hao <yhao016@ucr.edu>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG: divide error in ubi_attach_mtd_dev
Date: Sun, 23 Apr 2023 17:13:18 +0800 [thread overview]
Message-ID: <951e4cf7-a0ea-b3ec-931d-e6a394ddc2ab@huawei.com> (raw)
In-Reply-To: <1366603418.245114.1682236940160.JavaMail.zimbra@nod.at>
在 2023/4/23 16:02, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "chengzhihao1" <chengzhihao1@huawei.com>
>>>> root@syzkaller:~# cat /proc/mtd
>>>> dev: size erasesize name
>>>> mtd0: 00020000 00001000 “mtdram test device”
>>>
>>> Hmm, mtdram should be fine, erasesize is not zero.
>>>
>>
>> I guess the zero-erasesize mtd device is dynamically generated in
>> runtime, after looking through the code, I find erasesize is
>> initiallized in specific flash driver and it won't be updated later(eg.
>> ioctl\sysctl). And some mtd devices may have zero erasesize, eg.
>> drivers/mtd/devices/mchp23k256.c[1]. Unfortunately, I don't know how to
>> load/simulate this mtd, maybe it requires a real device? If we load this
>> mtd device as ubi, it will trigger the problem?
>
> Indeed. I guess qemu can emulate such chips.
> So better fix UBI to reject attaching of mtd's with erasesize being 0.
> (Please note, we cannot test for MTD_NO_ERASE, this one means there is no
> erase method).
Phram is an exception, it has erase function but is set flag
'MTD_CAP_RAM'. May I interpret 'MTD_NO_ERASE' as erase function is not
necessary?
next prev parent reply other threads:[~2023-04-23 9:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 5:10 BUG: divide error in ubi_attach_mtd_dev Yu Hao
2023-04-18 5:16 ` Yu Hao
2023-04-18 6:30 ` Richard Weinberger
2023-04-20 4:49 ` Zhihao Cheng
2023-04-20 17:27 ` Yu Hao
2023-04-20 17:33 ` Richard Weinberger
2023-04-20 18:14 ` Yu Hao
2023-04-20 20:36 ` Richard Weinberger
2023-04-23 3:20 ` Zhihao Cheng
2023-04-23 8:02 ` Richard Weinberger
2023-04-23 9:13 ` Zhihao Cheng [this message]
2023-10-02 10:11 ` Lee Jones
2023-10-02 10:28 ` Richard Weinberger
2023-10-02 14:04 ` Lee Jones
2023-10-02 14:15 ` Richard Weinberger
2023-10-02 14:36 ` Lee Jones
2023-06-20 9:17 ` admamiac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=951e4cf7-a0ea-b3ec-931d-e6a394ddc2ab@huawei.com \
--to=chengzhihao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=yhao016@ucr.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox