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

Gagan Sidhu
2024-06-20T22:06:40Z

hi zhihao,

so i assume my crude paraphrase is correct? that i may have unintentionally pointed the finger at you, but the real issue is GLUEBI existing with BLOCK on the same volume?

i was just joking about you being a spy by the way. it was post-fix euphoria ;)

master rich, shepherd weinberger, what say ye?

your wisdom and insight would be greatly appreciated as closure and maybe even a patch to reflect the beauty of collaborating over current ;)

Thanks,
Gagan

> On Jun 17, 2024, at 10:03 PM, Zhihao Cheng <chengzhihao1@huawei.com> wrote:
>
> 在 2024/6/18 6:13, Gagan Sidhu 写道:
> Hi,
>> spoke to a user, gave him a build without MTD_GLUEBI, restoring changes made by (HAHAHA you are! huawei), it booted fine.
>
> May I have the layers' information about mtd/ubi, you can get it by 'mtdinfo -a' and 'ubinfo -a' after booting the device.
> I guess your device boots from ubiblock0_0. There are two ways loading booting device:
> 1. mtd(nand)
> ubi(holds volume ubi0_0)
> mtd12 (gluebi)
> mtdblock12 (This way is cut by this patch, so mtdblock12 is not generated, just like Daniel&Richard analyzed)
> 2. mtd(nand)
> ubi(holds volume ubi0_0)
> ubiblock0_0
>
>> so we need to think about either deprecating GLUEBI or setting an option in the Kconfig that ensures they are mutually exclusive.
>> gluebi is definitely highjacking the block device created by UBI_BLOCK and adding the MTD_UBIVOLUME flag to it.
>
> The gluebi(mtd) and ubiblock could exist on the same UBI volume at the same time, but they cannot be opened at the same time. Here is an example I tested on the local machine:
>
> ↗ ubiblock0_0
> mtd0(nandsim) -> ubi0 (holds volume ubi0_0)
> ↘ gluebi(mtd1)
>
> [root@localhost ~]# ubinfo -a
> UBI version: 1
> Count of UBI devices: 1
> UBI control device major/minor: 10:61
> Present UBI devices: ubi0
>
> ubi0
> Volumes count: 1
> Logical eraseblock size: 126976 bytes, 124.0 KiB
> Total amount of logical eraseblocks: 8192 (1040187392 bytes, 992.0 MiB)
> Amount of available logical eraseblocks: 0 (0 bytes)
> Maximum count of volumes 128
> Count of bad physical eraseblocks: 0
> Count of reserved physical eraseblocks: 160
> Current maximum erase counter value: 2
> Minimum input/output unit size: 2048 bytes
> Character device major/minor: 246:0
> Present volumes: 0
>
> Volume ID: 0 (on ubi0)
> Type: dynamic
> Alignment: 1
> Size: 8026 LEBs (1019109376 bytes, 971.8 MiB)
> State: OK
> Name: vol_a
> Character device major/minor: 246:1
> [root@localhost ~]# mtdinfo -a
> Count of MTD devices: 2
> Present MTD devices: mtd0, mtd1
> Sysfs interface supported: yes
>
> mtd0
> Name: NAND simulator partition 0
> Type: nand
> Eraseblock size: 131072 bytes, 128.0 KiB
> Amount of eraseblocks: 8192 (1073741824 bytes, 1024.0 MiB)
> Minimum input/output unit size: 2048 bytes
> Sub-page size: 512 bytes
> OOB size: 64 bytes
> Character device major/minor: 90:0
> Bad blocks are allowed: true
> Device is writable: true
>
> mtd1
> Name: vol_a
> Type: ubi
> Eraseblock size: 126976 bytes, 124.0 KiB
> Amount of eraseblocks: 8026 (1019109376 bytes, 971.8 MiB)
> Minimum input/output unit size: 2048 bytes
> Sub-page size: 2048 bytes
> Character device major/minor: 90:2
> Bad blocks are allowed: false
> Device is writable: true
>
> [root@localhost ~]# lsblk | grep ubi
> ubiblock0_0 251:0 0 971.9M 0 disk
>
>> there is no other explanation.
>> looks like this was an absolutely amazing exchange that even furthered our understanding of wtf is going on.
>> thanks for being a great moderator for MTD rich
>> Thanks,
>> Gagan