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

[Gagan Sidhu]

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 at 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 at 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 at 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 at 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
>