Re: [PATCH] bcache:fix oops in cache_set_flush

> 2024年11月19日 12:19，liequan che <[email protected]> 写道：
> 

[snipped]

>>> 7. Repartition again, triggering kernel panic again.
>>> parted -s --align optimal /dev/nvme2n1 mkpart primary 2048s 1536GiB
>>> The same operation was performed on the other two servers, and no
>>> panic was triggered.
> 
>> I guess this is another undefine operation. I assume the cache device is still references somewhere. A reboot should follow the wipefs.
> Your guess is correct. In addition, after erasing the superblock
> information in CD rescue mode,
> I rebooted into the system where the original panic kernel was located.
> 

Please try latest upstream kernel and try whether you can see the issue.

c->root is allocated by __bch_btree_node_alloc(), it doesn’t return NULL pointer. 

Your kernel is 5.10 based distribution kernel, I am not able to help much here. If you may reproduce the oops in latest upstream kernel, it will be a surprise and please let me know.



>>> The server with the problem was able to enter the system normally
>>> after the root of the cache_set structure was determined to be empty.
>>> I updated the description of the problem in the link below.
> 
>> No, if you clean up the partition, no cache device will exist. Cache registration won’t treat it as a bcache device.
> 
>> OK, from the above description, I see you replace the backing device (and I don’t know where the previous data was), then you extend the cache device size. They are all unsupported operations.
> The behavior here is a bit strange. After partitioning, I may have
> recreated the bcache device here,
> which triggered the bcache rigister operation. Then the kernel panicked again.

When you mention your operations, it is better to provide exact detailed command lines, otherwise maybe I will misunderstand you.

After all, please try the latest upstream kernel. Not the distro kernel. Otherwise I am not able to help.

Coly Li