linux-kernel - Re: [PATCH] bcache:fix oops in cache_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <0CFF2B9E-4E40-480D-9F3B-F7631FE3CEA5@suse.de>
Date: Tue, 26 Nov 2024 23:38:52 +0800
From: Coly Li <colyli@...e.de>
To: liequan che <liequanche@...il.com>
Cc: "mingzhe.zou@...ystack.cn" <mingzhe.zou@...ystack.cn>,
 Kent Overstreet <kent.overstreet@...il.com>,
 linux-bcache <linux-bcache@...r.kernel.org>,
 linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bcache:fix oops in cache_set_flush



> 2024年11月19日 12:19，liequan che <liequanche@...il.com> 写道：
> 

[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