From: Christian Lamparter <chunkeey@gmail.com>
To: linux-mtd@lists.infradead.org
Cc: david.oberhollenzer@sigma-star.at
Subject: Regression due to "Return correct error number in ubi_get_vol_info1" in mtd-utils 2.0.1+
Date: Thu, 07 Jun 2018 22:35:22 +0200 [thread overview]
Message-ID: <2542341.JDPxxHf69l@debian64> (raw)
Hello,
the commit "Return correct error number in ubi_get_vol_info1" [0]
causes an regression within the libubi of mtd-utils. Affected
by this is ubinfo, ubirmvol and ubirsvol (basically all tools that
use "ubi_get_vol_info1" and check for ENOENT error code).
steps to reproduce: have mtd-utils 2.0.1 or 2.0.2
0. make a bunch of ubi volumes in sequential order
# ubimkvol /dev/ubi0 -s 64KiB -N test1
# ubimkvol /dev/ubi0 -s 64KiB -N test2
# ubimkvol /dev/ubi0 -s 64KiB -N test3
# ubimkvol /dev/ubi0 -s 64KiB -N test4
..
(The idea is that the volume ID of test4 is bigger than
of test1).
1. delete the test1 volume
# ubirmvol /dev/ubi0 -N test1
(this makes a hole in the volume table)
2. try an affected tool (i.e. "ubirmvol /dev/ubi0 -N test4" )
|root@mr24:/# ubirmvol /dev/ubi0 -N test4
|ubirmvol: error!: cannot find UBI volume "test4"
| error 19 (No such device)
or "ubinfo -a"
| root@mr24:/# ubinfo -a
| UBI version: 1
| Count of UBI devices: 1
| UBI control device major/minor: 10:59
| Present UBI devices: ubi0
|
| ubi0
| Volumes count: 11
| Logical eraseblock size: 15872 bytes, 15.5 KiB
| Total amount of logical eraseblocks: 1952 (30982144 bytes, 29.5 MiB)
| Amount of available logical eraseblocks: 75 (1190400 bytes, 1.1 MiB)
| Maximum count of volumes 92
| Count of bad physical eraseblocks: 0
| Count of reserved physical eraseblocks: 40
| Current maximum erase counter value: 984
| Minimum input/output unit size: 512 bytes
| Character device major/minor: 251:0
| ubinfo: error!: libubi failed to probe volume 5 on ubi0
| error 19 (No such device)
| Present volumes: 0, 1, 2, 3, 4root@mr24:/#
The problem with this patch is, that it updated ubi_get_vol_info1() to
return a different errno code (ENODEV instead of ENOENT).
|- if (vol_get_major(lib, dev_num, vol_id, &info->major, &info->minor))
|+ if (vol_get_major(lib, dev_num, vol_id, &info->major, &info->minor)) {
|+ if (errno == ENOENT)
|+ errno = ENODEV;
| return -1;
|+ }
However, the patch didn't update any existing code. For example this
loop @ line 1327 in ubi_get_vol_info1_nm() [1]
|1327 for (i = dev_info.lowest_vol_id;
|1328 i <= dev_info.highest_vol_id; i++) {
|1329 err = ubi_get_vol_info1(desc, dev_num, i, info);
|1330 if (err == -1) {
|1331 if (errno == ENOENT)
|1332 continue;
|1333 return -1;
|1334 }
|1335
|1336 if (nlen == strlen(info->name) && !strcmp(name, info->name))
|1337 return 0;
|1338 }
will now fail with the aforementioned ENODEV error, instead of
skipping deleted entry.
the same is true for ubinfo [2]:
| 266 for (i = dev_info.lowest_vol_id;
| 267 i <= dev_info.highest_vol_id; i++) {
| 268 err = ubi_get_vol_info1(libubi, dev_info.dev_num, i, &vol_info);
| 269 if (err == -1) {
| 270 if (errno == ENOENT)
| 271 continue;
| 272
| 273 return sys_errmsg("libubi failed to probe volume %d on ubi%d",
| 274 i, dev_info.dev_num);
| 275 }
reverting the patch [0] would probably be the easiest
way to fix the issue, but I'm not sure if that's the
best course of action. If somebody has an idea or
different opinion, please: hit "reply all" ;-).
Regards,
Christian Lamparter
[0] <http://git.infradead.org/mtd-utils.git/commitdiff/dede98ffb706676309488d7cc660f569548d5930>
[1] <http://git.infradead.org/mtd-utils.git/blob/bc63d36e39f389c8c17f6a8e9db47f2acc884659:/lib/libubi.c#l1327>
[2] <http://git.infradead.org/mtd-utils.git/blob/HEAD:/ubi-utils/ubinfo.c#l268>
next reply other threads:[~2018-06-07 20:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-07 20:35 Christian Lamparter [this message]
2018-06-10 5:24 ` Regression due to "Return correct error number in ubi_get_vol_info1" in mtd-utils 2.0.1+ David Oberhollenzer
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=2542341.JDPxxHf69l@debian64 \
--to=chunkeey@gmail.com \
--cc=david.oberhollenzer@sigma-star.at \
--cc=linux-mtd@lists.infradead.org \
/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