Message-Id: <90A90DA4-8B68-432D-9577-0D3635AF84BB@mac.com>
Date: Mon, 17 Jun 2024 12:18:18 -0600
From: Gagan Sidhu <broly@....com>
To: Richard Weinberger <richard@....at>
Cc: ZhaoLong Wang <wangzhaolong1@...wei.com>,
 chengzhihao1 <chengzhihao1@...wei.com>,
 dpervushin <dpervushin@...eddedalley.com>,
 linux-kernel <linux-kernel@...r.kernel.org>,
 linux-mtd <linux-mtd@...ts.infradead.org>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 Vignesh Raghavendra <vigneshr@...com>,
 yangerkun <yangerkun@...wei.com>,
 yi zhang <yi.zhang@...wei.com>
Subject: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by
 ftl notifier



> On Jun 17, 2024, at 12:09 PM, Richard Weinberger <richard@....at> wrote:
> 
> ----- Ursprüngliche Mail -----
>> Von: "Gagan Sidhu" <broly@....com>
>> https://github.com/torvalds/linux/blob/master/drivers/mtd/ubi/gluebi.c#L297
>> 
>> it seems the GLUEBI is setting the mtd to MTD_UBIVOLUME
>> 
>> https://github.com/torvalds/linux/blob/master/drivers/mtd/ubi/block.c
>> 
>> where this doesn’t even have the text “mtd” anywhere.
>> 
>> but the boot partition is always the ubiblock device.
>> 
>> so is gluebi taking the same volume and adding the MTD_UBIVOLUME label or
>> something?
> 
> Yes, GLUEBI emulates a MTD on top of an UBI volume.
> It sets the MTD device type to MTD_UBIVOLUME.
> 
>>> 
>>> [    5.462504] auto-attach mtd7
>>> [    5.462525] ubi0: default fastmap pool size: 15
>>> [    5.477309] ubi0: default fastmap WL pool size: 7
>>> [    5.486683] ubi0: attaching mtd7
>>> [    5.811240] UBI: EOF marker found, PEBs from 273 will be erased
>>> [    5.811299] ubi0: scanning is finished
>>> [    5.874546] gluebi (pid 1): gluebi_resized: got update notification for
>>> unknown UBI device 0 volume 1
>>> [    5.892927] ubi0: volume 1 ("rootfs_data") re-sized from 9 to 28 LEBs
>>> [    5.906683] ubi0: attached mtd7 (name "ubi", size 40 MiB)
>>> [    5.917446] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
>>> [    5.931132] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
>>> [    5.944654] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
>>> [    5.958513] ubi0: good PEBs: 320, bad PEBs: 0, corrupted PEBs: 0
>>> [    5.970472] ubi0: user volume: 2, internal volumes: 1, max. volumes count:
>>> 128
>>> [    5.984859] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
>>> sequence number: 1613475955
>>> [    6.003045] ubi0: available PEBs: 0, total reserved PEBs: 320, PEBs reserved
>>> for bad PEB handling: 15
>>> [    6.021426] rootfs: parsing partitions cmdlinepart
>>> [    6.021444] ubi0: background thread "ubi_bgt0d" started, PID 97
>>> [    6.043694] rootfs: got parser (null)
>>> [    6.051426] mtd: device 12 (rootfs) set to be root filesystem
> 
> AFAICT, this log line is not part of the mainline kernel.

this is mainline. it’s just not 6.x. it’s 4.14.
> 
>>> [    6.062891] rootfs_data: parsing partitions cmdlinepart
>>> [    6.073669] rootfs_data: got parser (null)
>>> [    6.211240] block ubiblock0_0: created from ubi0:0(rootfs)
>>> [    6.259545] rtc-pcf8563 0-0051: hctosys: unable to read the hardware clock
>>> [    6.282125] VFS: Cannot open root device "(null)" or unknown-block(31,12):
>>> error -6
>>> [    6.297406] Please append a correct "root=" boot option; here are the
>>> available partitions:
>>> [    6.314054] 1f00             512 mtdblock0
>>> [    6.314060]  (driver?)
>>> [    6.327077] 1f01             256 mtdblock1
>>> [    6.327081]  (driver?)
>>> [    6.340101] 1f02             256 mtdblock2
>>> [    6.340105]  (driver?)
>>> [    6.353124] 1f03             256 mtdblock3
>>> [    6.353129]  (driver?)
>>> [    6.366153] 1f04           45056 mtdblock4
>>> [    6.366158]  (driver?)
>>> [    6.379175] 1f05           40572 mtdblock5
>>> [    6.379179]  (driver?)
>>> [    6.392217] 1f06            4096 mtdblock6
>>> [    6.392222]  (driver?)
>>> [    6.405240] 1f07           40960 mtdblock7
>>> [    6.405244]  (driver?)
>>> [    6.418272] 1f08           32768 mtdblock8
>>> [    6.418277]  (driver?)
>>> [    6.431296] 1f09           40960 mtdblock9
>>> [    6.431300]  (driver?)
>>> [    6.444324] 1f0a            6144 mtdblock10
>>> [    6.444328]  (driver?)
>>> [    6.457518] 1f0b            4608 mtdblock11
>>> [    6.457523]  (driver?)
>>> [    6.470720] fe00           33604 ubiblock0_0
>>> [    6.470724]  (driver?)
>>> [    6.484090] Kernel panic - not syncing: VFS: Unable to mount root fs on
>>> unknown-block(31,12)
> 
> (31, 12) would be mtdblock12.
> How does your kernel know that mtdblock12 shall be the rootfs?

this is an openwrt approach: https://openwrt.org/docs/techref/filesystems (under “technical details”, third paragraph)

essentially there’s a feature they add to the kernel (via patch) where you can enable a feature that sets the root device based on the name of the partition.

in this case as long as the volume within your ubi file contains the name “rootfs”, openwrt will follow it as it gets unpacked and set that as the rootdevice for you.

—

> 
> I have a hard time understanding your current setup.

i think we are saying the same thing when you say (31,12) is mtdblock12, which is shown as ubiblock0_0, because once i remove the change under discussion here, the boot is fine. 

is it possible that gluebi is adding properties to the device created by CONFIG_MTD_UBI_BLOCK or something like that?

i wouldn’t worry about how the kernel knows which partition to set as root. openwrt has been doing this for over ten years. 

the real question is, if we know what partition to set as root (ubiblock0_0 or mtdblock12), why does this change prevent it from finishing the boot?

the only explanation seems to be that gluebi is adding features to the ubiblock0_0 device (MTD_UBIVOLUME)?



> 
> Thanks,
> //richard

Powered by blists - more mailing lists