Report: mtd-utils: "Floating point exception" with ubiformat

Report: mtd-utils: "Floating point exception" with ubiformat

[hujianyang]

Hi,

Here is an interesting problem. I used a nand flash driver with
wrong partition table and an error like this occurred:

# insmod nandflash.ko

[454096.098834] mtd: partition "ubi1" is out of reach -- disabled


The display of /proc/mtd shows the size of mtd1 is zero:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubi0"
mtd1: 00000000 00000000 "ubi1"
mtd2: 20000000 00020000 "rest"


When performing ubiformat with this mtd1, the utility breaks
down with a message:

# ubiformat /dev/mtd1
Floating point exception


I used to think it is because ubiformat can't deal with a zero
size MTD device. So I want to add something like a error branch
for this. But now I find it is because the "erasesize" in
"/sys/class/mtd/mtd1" is zero.

:/sys/class/mtd/mtd1# cat erasesize
0

So function mtd_get_dev_info1() in lib/libmtd.c, line 777

"""
mtd->eb_cnt = mtd->size / mtd->eb_size;
"""

will crash the program because mtd->eb_size is zero.


Do you think it is a valuable problem to deal with? Keep the
existing logic is OK. But can we add something in mtd-utils
to indicate this error than "Floating point exception"?


Thanks~!

Hu

Re: Report: mtd-utils: "Floating point exception" with ubiformat

[Artem Bityutskiy]

On Fri, 2014-10-31 at 18:36 +0800, hujianyang wrote:
> Do you think it is a valuable problem to deal with? Keep the
> existing logic is OK. But can we add something in mtd-utils
> to indicate this error than "Floating point exception"?

I think a work-around in mtd-utils is needed for sure. Because even if
we change the kernel, the change will only affect new kernels.

And I think changing the kernel is worthwhile too. It is extremely
unlikely, in my opinion, that someone relies on this illogical behavior
which happens only for zero-size partitions.  May be we can also
disallow zero-size partitions?

Artem.

Re: Report: mtd-utils: "Floating point exception" with ubiformat

[hujianyang]

On 2014/11/7 17:43, Artem Bityutskiy wrote:
> On Fri, 2014-10-31 at 18:36 +0800, hujianyang wrote:
>> Do you think it is a valuable problem to deal with? Keep the
>> existing logic is OK. But can we add something in mtd-utils
>> to indicate this error than "Floating point exception"?
> 
> I think a work-around in mtd-utils is needed for sure. Because even if
> we change the kernel, the change will only affect new kernels.
> 
> And I think changing the kernel is worthwhile too. It is extremely
> unlikely, in my opinion, that someone relies on this illogical behavior
> which happens only for zero-size partitions.  May be we can also
> disallow zero-size partitions?
> 
> Artem.
> 
> 
> 

I'm agree with you.

I found another strange thing, also caused by the wrong partition
table.

In my board there is only one 512M nand flash. But the partition
table in nand driver is used for a board with 2G(4*512M) nand flash.

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubi0"
mtd1: 00000000 00000000 "ubi1"
mtd2: 20000000 00020000 "rest"


The /proc/mtd shows there are two 512M nand flash but actually
they share the same device.

If I format mtdblock0 as jffs2 and then, I can mount a jffs2 file
system from mtdblock2. Very interesting~!

Hu

Re: Report: mtd-utils: "Floating point exception" with ubiformat

[Artem Bityutskiy]

On Fri, 2014-11-07 at 18:03 +0800, hujianyang wrote:
> The /proc/mtd shows there are two 512M nand flash but actually
> they share the same device.
> 
> If I format mtdblock0 as jffs2 and then, I can mount a jffs2 file
> system from mtdblock2. Very interesting~!

The partitioning code is old and hairy, and needs love.

Artem.