| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CY5PR11MB63662D21B2C7B1A1C2E6BC4BED6BA@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Mon, 9 Jun 2025 15:16:27 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: Guenter Roeck <linux@...ck-us.net>, Miquel Raynal
<miquel.raynal@...tlin.com>
CC: Richard Weinberger <richard@....at>, Vignesh Raghavendra
<vigneshr@...com>, "De Marchi, Lucas" <lucas.demarchi@...el.com>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@...el.com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin
<tursulin@...ulin.net>, "Poosa, Karthik" <karthik.poosa@...el.com>, "Abliyev,
Reuven" <reuven.abliyev@...el.com>, "Weil, Oren jer"
<oren.jer.weil@...el.com>, "linux-mtd@...ts.infradead.org"
<linux-mtd@...ts.infradead.org>, "dri-devel@...ts.freedesktop.org"
<dri-devel@...ts.freedesktop.org>, "intel-gfx@...ts.freedesktop.org"
<intel-gfx@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v6 01/11] mtd: core: always create master device
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> On 6/9/25 05:23, Usyskin, Alexander wrote:
> >> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> >>
> >>
> >>>>>> Several of my qemu boot tests fail to boot from mtd devices with this
> >> patch
> >>>>>> in the mainline kernel. Reverting it fixes the problem. As far as I can
> >>>>>> see this affects configurations with
> >> CONFIG_MTD_PARTITIONED_MASTER=y
> >>>>>> when
> >>>>>> trying to boot from an mtd partition other than mtdblock0, with the
> >>>>>> mtd partition data in devicetree (.../aspeed/openbmc-flash-
> layout.dtsi).
> >>>>>> Is there a guidance describing the changed behavior, by any chance,
> >>>>>> and how the boot command line now needs to look like when using
> one
> >> of
> >>>>>> the flash partitions as root file system ?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Guenter
> >>>>>
> >>>>> I've tried to make is as transparent as possible for the existing users.
> >>>>> Only change is that now every partition has master that is not
> partitioned.
> >>>>> Is the CONFIG_MTD_PARTITIONED_MASTER=n fixed the problem for
> you?
> >>>> No change is expected, can you please describe the devices that you
> >>>> observe with and without the patch? Maybe there is something wrong in
> >>>> the core logic.
> >>>>
> >>>
> >>> I am trying to boot supermicro-x11spi-bmc in qemu from flash partition 6.
> >>> The qemu command line is something like
> >>>
> >>> qemu-system-arm -M supermicro-x11spi-bmc,fmc-
> >> model=n25q256a13,spi-model=n25q256a13 \
> >>> -kernel arch/arm/boot/zImage -no-reboot -snapshot \
> >>> -audio none \
> >>> -drive file=/tmp/flash,format=raw,if=mtd,index=1 \
> >>> -nic user \
> >>> --append "root=/dev/mtdblock6 rootwait console=ttyS4,115200
> >> earlycon=uart8250,mmio32,0x1e784000,115200n8" \
> >>> -dtb arch/arm/boot/dts/aspeed/aspeed-bmc-supermicro-x11spi.dtb
> >> \
> >>> -nographic -monitor null -serial stdio
> >>>
> >>> This is with aspeed_g5_defconfig. Note that the flash models need to be
> >> specified.
> >>> The default flashes are no longer recognized when booting from qemu
> since
> >> commit
> >>> 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
> >> fields").
> >>>
> >>> The above only works with this patch reverted (or with v6.15 and older, of
> >> course).
> >>>
> >>> Guenter
> >>
> >> Alexander, can you please investigate? We need a fix because Guenter
> >> might not be the only affecter user. Otherwise this patch can't stand,
> >> unfortunately.
> >>
> >> Thanks,
> >> Miquèl
> >
> > Maybe something is moved, and it is not /dev/mtdblock6 now.
> >
>
> With this patch:
>
> # ls -l /dev/*mtd*
> crw------- 1 root root 90, 0 Jan 1 00:00 /dev/mtd0
> crw------- 1 root root 90, 1 Jan 1 00:00 /dev/mtd0ro
> crw------- 1 root root 90, 2 Jan 1 00:00 /dev/mtd1
> crw------- 1 root root 90, 3 Jan 1 00:00 /dev/mtd1ro
> crw------- 1 root root 244, 0 Jan 1 00:00 /dev/mtd_master0
> crw------- 1 root root 244, 1 Jan 1 00:00 /dev/mtd_master1
> brw------- 1 root root 31, 0 Jan 1 00:00 /dev/mtdblock0
> brw------- 1 root root 31, 1 Jan 1 00:00 /dev/mtdblock1
> ~ # ls /proc/mtd
> /proc/mtd
> ~ # cat /proc/mtd
> dev: size erasesize name
> mtd0: 02000000 00010000 "bmc"
> mtd1: 02000000 00010000 "pnor"
>
> After reverting it:
>
> # ls -l /dev/mtd*
> crw------- 1 root root 90, 0 Jan 1 00:00 /dev/mtd0
> crw------- 1 root root 90, 1 Jan 1 00:00 /dev/mtd0ro
> crw------- 1 root root 90, 2 Jan 1 00:00 /dev/mtd1
> crw------- 1 root root 90, 3 Jan 1 00:00 /dev/mtd1ro
> crw------- 1 root root 90, 4 Jan 1 00:00 /dev/mtd2
> crw------- 1 root root 90, 5 Jan 1 00:00 /dev/mtd2ro
> crw------- 1 root root 90, 6 Jan 1 00:00 /dev/mtd3
> crw------- 1 root root 90, 7 Jan 1 00:00 /dev/mtd3ro
> crw------- 1 root root 90, 8 Jan 1 00:00 /dev/mtd4
> crw------- 1 root root 90, 9 Jan 1 00:00 /dev/mtd4ro
> crw------- 1 root root 90, 10 Jan 1 00:00 /dev/mtd5
> crw------- 1 root root 90, 11 Jan 1 00:00 /dev/mtd5ro
> crw------- 1 root root 90, 12 Jan 1 00:00 /dev/mtd6
> crw------- 1 root root 90, 13 Jan 1 00:00 /dev/mtd6ro
> brw------- 1 root root 31, 0 Jan 1 00:00 /dev/mtdblock0
> brw------- 1 root root 31, 1 Jan 1 00:00 /dev/mtdblock1
> brw------- 1 root root 31, 2 Jan 1 00:00 /dev/mtdblock2
> brw------- 1 root root 31, 3 Jan 1 00:00 /dev/mtdblock3
> brw------- 1 root root 31, 4 Jan 1 00:00 /dev/mtdblock4
> brw------- 1 root root 31, 5 Jan 1 00:00 /dev/mtdblock5
> brw------- 1 root root 31, 6 Jan 1 00:00 /dev/mtdblock6
> ~ # cat /proc/mtd
> dev: size erasesize name
> mtd0: 02000000 00010000 "bmc"
> mtd1: 00060000 00010000 "u-boot"
> mtd2: 00020000 00010000 "u-boot-env"
> mtd3: 00440000 00010000 "kernel"
> mtd4: 01740000 00010000 "rofs"
> mtd5: 00400000 00010000 "rwfs"
> mtd6: 02000000 00010000 "pnor"
>
> I am trying to boot from "pnor". It looks like the partition data (from
> devicetree)
> is now ignored. mtdblock6 used to be the second flash.
>
> Guenter
Is this with CONFIG_MTD_PARTITIONED_MASTER?
I think that mtd_is_partition is ambiguous now.
We always have master partition when CONFIG_MTD_PARTITIONED_MASTER
is enabled and parent check is useless.
We must check grandparent in this case.
Miquel, am I right?
We can return to older patch version that have created partition
instead of the master device.
Or try to fix mtd_is_partition, like below.
Guenter, is below patch helps?
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 429d8c16baf0..b977dce6d58c 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -104,7 +104,7 @@ static void mtd_release(struct device *dev)
idr_remove(&mtd_idr, mtd->index);
of_node_put(mtd_get_of_node(mtd));
- if (mtd_is_partition(mtd))
+ if (mtd_is_partition_or_master_partiton(mtd))
release_mtd_partition(mtd);
/* remove /dev/mtdXro node */
@@ -118,7 +118,7 @@ static void mtd_master_release(struct device *dev)
idr_remove(&mtd_master_idr, mtd->index);
of_node_put(mtd_get_of_node(mtd));
- if (mtd_is_partition(mtd))
+ if (mtd_is_partition_or_master_partiton(mtd))
release_mtd_partition(mtd);
}
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 8d10d9d2e830..05271458c4db 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -419,6 +419,15 @@ static inline u64 mtd_get_master_ofs(struct mtd_info *mtd, u64 ofs)
}
static inline bool mtd_is_partition(const struct mtd_info *mtd)
+{
+ if (!mtd->parent)
+ return false;
+ if (IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER) && !mtd->parent->parent)
+ return false;
+ return true;
+}
+
+static inline bool mtd_is_partition_or_master_partiton(const struct mtd_info *mtd)
{
return mtd->parent;
}
Powered by blists - more mailing lists