[PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by ftl notifier

[Richard Weinberger]

[CC'ing Daniel]

----- Ursprüngliche Mail -----
> Von: "Gagan Sidhu" <broly at mac.com>
> An: "richard" <richard at nod.at>
> CC: "ZhaoLong Wang" <wangzhaolong1 at huawei.com>, "chengzhihao1" <chengzhihao1 at huawei.com>, "dpervushin"
> <dpervushin at embeddedalley.com>, "linux-kernel" <linux-kernel at vger.kernel.org>, "linux-mtd"
> <linux-mtd at lists.infradead.org>, "Miquel Raynal" <miquel.raynal at bootlin.com>, "Vignesh Raghavendra" <vigneshr at ti.com>,
> "yangerkun" <yangerkun at huawei.com>, "yi zhang" <yi.zhang at huawei.com>
> Gesendet: Montag, 17. Juni 2024 20:46:10
> Betreff: Re: [PATCH v2] ubi: gluebi: Fix NULL pointer dereference caused by ftl notifier

>> On Jun 17, 2024, at 12:32 PM, Richard Weinberger <richard at nod.at> wrote:
>> 
>> ----- Ursprüngliche Mail -----
>>> Von: "Gagan Sidhu" <broly at mac.com>
>>>> AFAICT, this log line is not part of the mainline kernel.
>>> 
>>> this is mainline. it’s just not 6.x. it’s 4.14.
>> 
>> I've double checked and disagree.
>> This line comes from:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-4.14/480-mtd-set-rootfs-to-be-root-dev.patch;h=6cddaf01b75cb58cfb377f568f2c375af87e2f1b;hb=c3bd1321de1e0d814f5cfc4f494f6b2fb1f5133b
> 
> no i know that, that’s the patch i showed you. i meant the rest of it is
> mainline. the patch obviously is not.
>> 
>> In recent OpenWRT kernels I see:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-5.15/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch;h=266a6331c2acc0f7c17d9ac72f54659d31b56249;hb=HEAD
>> 
>> Looks like in recent versions the patch in question does *not* cause a
>> regression.
> 
> that patch is also applied in my version as well, so i don’t see how this avoids
> the regression.
> 
> https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdcore.c#L774
> 
> mine says "[6.051426] mtd: device 12 (rootfs) set to be root filesystem"
> 
> which is simply the call from drivers/mtd/mtdcore.c
> 
> so the rootfs device is set correctly. it’s just not booting from it.
> 
> the regression comes from having GLUEBI+BLOCK enabled, it seems, are they
> fighting for/operating on the same partition?

I don't know. Let's ask Daniel.

> 
>> 
>>>> (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.
>> 
>> So, this is all not mainline. :-/
> 
> i did say openwrt at the start, and i think that’s pretty close to mainline as
> it gets.
> 
> sometimes these patches aren’t appropriate to push upstream. this one is not the
> one causing the issue.
> 
> it seems to me that there is a problem with GLUEBI+BLOCK playing together.
> 
> as far as i can see, the setting of the device is being doing by mtdcore.c
> 
> it’s just not working with gluebi and block are enabled, and i need to know
> whether disabling gluebi will allow it to work.
> 
> in other words, is it possible for gluebi to use the partition created by
> ubi_block, and add the MTD_UBIVOLUME flag?

No. UBIBlock works on top of UBI volumes and creates a block device.

We'll sort this out. :)

Thanks,
//richard