在 2024/2/9 15:09, Martin Kepplinger-Novakovic 写道:
Am Montag, dem 22.01.2024 um 15:56 -0800 schrieb Greg Kroah-Hartman:
5.4-stable review patch. If anyone has any objections, please let me know.
From: ZhaoLong Wang wangzhaolong1@huawei.com
[ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ]
[...]
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index 0c05f77f9b21..dd0d0bf5f57f 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -533,7 +533,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) { struct mtd_blktrans_ops *tr; - if (mtd->type == MTD_ABSENT) + if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) return; list_for_each_entry(tr, &blktrans_majors, list) @@ -576,7 +576,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) list_add(&tr->list, &blktrans_majors); mtd_for_each_device(mtd) - if (mtd->type != MTD_ABSENT) + if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) tr->add_mtd(tr, mtd); mutex_unlock(&mtd_table_mutex);
Hi Greg, hi patch-developers,
wait a second. this already went into v5.4.268 but still: Doesn't this break userspace?
According to https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@n... where this solution seems to come from, the behaviour changes: "no mtdblock (hence, also no FTLs) on top of gluebi."
I fell accross this because of an out-of-tree module that does sys_mount() an mtdblock, so I won't complain about my code specifically :) But doesn't it break mounting, say, jffs2 inside an ubi via mtdblock? If so, is this really something that you want to see backported to old kernels?
Or differently put: Has this patch been picked up for old stable kernels by scripts or by a human?
I just want to make sure, and who knows, it might help others too, who would just do a (possibly dangerous?) revert in their trees.
This change does affect the mounting(mtdblock based on gluebi) behavior in userspace. It was picked into stable versions because the fixed problem is serious and easy to be reproduced, I guess. A temporary solution is that modify mounting source target in userspace, just replace mtdblock with mtd char device. For example, mount -t jffs2 mtd0 /mnt