Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped)
To better handle this and still keep some kind of error tracking (for example to catch -ENOMEM errors or -EINVAL errors), permit parser on subpartition to emit -ENOENT error, print a debug log and skip them accordingly.
This results in giving better tracking of the status of the parser (instead of returning just 0, dropping any kind of signal that there is something wrong with the parser) and to some degree restore the original logic of the subpartitions parse.
(worth to notice that some special partition might have all the special header present for the parser and declare 0 partition in it, this is why it would be wrong to simply return 0 in the case of a special partition that is NOT init for the scanning parser)
Cc: stable@vger.kernel.org Fixes: 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") Signed-off-by: Christian Marangi ansuelsmth@gmail.com --- drivers/mtd/mtdpart.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index 994e8c51e674..2876501a7814 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -425,9 +425,12 @@ int add_mtd_partitions(struct mtd_info *parent,
mtd_add_partition_attrs(child);
- /* Look for subpartitions */ + /* Look for subpartitions (skip if no maching parser found) */ ret = parse_mtd_partitions(child, parts[i].types, NULL); - if (ret < 0) { + if (ret < 0 && ret == -ENOENT) { + pr_debug("Skip parsing subpartitions: %d\n", ret); + continue; + } else if (ret < 0) { pr_err("Failed to parse subpartitions: %d\n", ret); goto err_del_partitions; }
Hi Christian,
On 09/11/2025 at 12:52:44 +01, Christian Marangi ansuelsmth@gmail.com wrote:
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped)
I didn't had in mind this was a valid case. I am a bit puzzled because it opens the breach to other special cases, but at the same time I have no strong arguments to refuse this situation so let's go for it.
Thanks, Miquèl
On Wed, Nov 12, 2025 at 10:33:25AM +0100, Miquel Raynal wrote:
Hi Christian,
On 09/11/2025 at 12:52:44 +01, Christian Marangi ansuelsmth@gmail.com wrote:
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped)
I didn't had in mind this was a valid case. I am a bit puzzled because it opens the breach to other special cases, but at the same time I have no strong arguments to refuse this situation so let's go for it.
Thanks a lot for accepting this. I checked all the parser both upstream and downstream and I found this ""undocumented"" pattern of returning -ENOENT. [1] [2] [3]
For sure it's a regression, we had various device on OpenWrt that broke from migrating from 6.6 to 6.12. I agree there is the risk you are pointing out but I feel this is a good compromise to restore original functionality of the upstream parsers.
(the other error condition are -ENOMEM or sometimes -EINVAL for parser header present but very wrong)
[1] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/tplink_s... [2] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/scpart.c... [3] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/ofpart_b...
On 12/11/2025 at 10:43:17 +01, Christian Marangi ansuelsmth@gmail.com wrote:
On Wed, Nov 12, 2025 at 10:33:25AM +0100, Miquel Raynal wrote:
Hi Christian,
On 09/11/2025 at 12:52:44 +01, Christian Marangi ansuelsmth@gmail.com wrote:
Commit 5c2f7727d437 ("mtd: mtdpart: check for subpartitions parsing result") introduced some kind of regression with parser on subpartitions where if a parser emits an error then the entire parsing process from the upper parser fails and partitions are deleted.
Not checking for error in subpartitions was originally intended as special parser can emit error also in the case of the partition not correctly init (for example a wiped partition) or special case where the partition should be skipped due to some ENV variables externally provided (from bootloader for example)
One example case is the TRX partition where, in the context of a wiped partition, returns a -ENOENT as the trx_magic is not found in the expected TRX header (as the partition is wiped)
I didn't had in mind this was a valid case. I am a bit puzzled because it opens the breach to other special cases, but at the same time I have no strong arguments to refuse this situation so let's go for it.
Thanks a lot for accepting this. I checked all the parser both upstream and downstream and I found this ""undocumented"" pattern of returning -ENOENT. [1] [2] [3]
For sure it's a regression, we had various device on OpenWrt that broke from migrating from 6.6 to 6.12. I agree there is the risk you are pointing out but I feel this is a good compromise to restore original functionality of the upstream parsers.
(the other error condition are -ENOMEM or sometimes -EINVAL for parser header present but very wrong)
[1] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/tplink_s... [2] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/scpart.c... [3] https://elixir.bootlin.com/linux/v6.17.7/source/drivers/mtd/parsers/ofpart_b...
Thanks for the digging. I will apply this to -next and not -fixes. It will be slightly longer to get it backported, but this gives a bit more time for this patch to be thought about as I plan on sending my fixes PR in the next days.
Miquèl
linux-stable-mirror@lists.linaro.org