linux-kernel - Re: [PATCH v2] bcache: use bio cloning for detached device requests

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] [day] [month] [year] [list]

Message-Id: <EA9A1644-0B59-4945-87D6-E67C65C4E4A3@fnnas.com>
Date: Thu, 22 Jan 2026 11:39:25 +0800
From: "Coly Li" <colyli@...as.com>
To: "Jens Axboe" <axboe@...nel.dk>
Cc: "Stephen Zhang" <starzhangzsd@...il.com>, 
	"Kent Overstreet" <kent.overstreet@...ux.dev>, 
	"Sasha Levin" <sashal@...nel.org>, 
	"Christoph Hellwig" <hch@...radead.org>, <linux-bcache@...r.kernel.org>, 
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, 
	"zhangshida" <zhangshida@...inos.cn>
Subject: Re: [PATCH v2] bcache: use bio cloning for detached device requests

> 2026年1月21日 22:50，Jens Axboe <axboe@...nel.dk> 写道：
> 
> On 1/21/26 4:55 AM, Stephen Zhang wrote:
>> Coly Li <colyli@...as.com> 于2026年1月21日周三 09:34写道：
>>> 
>>> On Tue, Jan 20, 2026 at 08:01:52AM +0800, Jens Axboe wrote:
>>>> On 1/20/26 7:46 AM, Coly Li wrote:
>>>>>> @@ -949,6 +950,11 @@ static int bcache_device_init(struct
>>>>>> bcache_device *d, unsigned int block_size,
>>>>>>                        BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER))
>>>>>>                goto out_ida_remove;
>>>>>> 
>>>>>> +       if (bioset_init(&d->bio_detach, 4,
>>>>>                                    ^^^^^-> I feel 4 might be a bit small
>>>>> here. bio_detached set is for normal IO when backing device is not
>>>>> attached to a cache device. I would suggest to set the pool size to
>>>>> 128 or 256.
>>>> 
>>>> Absolutely not, 4 is more than plenty. The pool elements are only ever
>>>> used if allocations fail, to guarantee forward progress. Setting aside
>>>> 128 or 256 for that case is utterly wasteful, you only need a couple. 4
>>>> is a good number, if anything it should be smaller (2).
>>> 
>>> Hi Jens,
>>> 
>>> Thanks for the information. Please correct me if I am wrong for the following
>>> text,
>>> - If the backing is a normal SSD raid0, the IOPS without attached cache device
>>> might be more than thousands. In this case, I assume 128 or 256 might be more
>>> tolerant.
>>> - I see what ‘4’ means, just not sure/comfortable when memory pressure is high.
>>> And reserving 128/256 will occupy around 0.5~1MB memory, I feel such extra
>>> memory is acceptable in bcache use case.
>>> 
>>> Don't get me wrong, I totally trust you. If '4' works well enough for high
>>> memory pressure condition for detached bcache device, it is cool.
>>> 
>>> Thanks in advance.
>>> 
>>> Coly Li
>> 
>> Hi Jens, Coly,
>> 
>> Regarding the discussion on the bio_detached pool size: while 4 is
>> sufficient to guarantee forward progress, some high-load environments
>> may prefer a larger reserve to minimize allocation latency under
>> extreme memory pressure.
>> 
>> To provide a middle ground, I propose adding a generic bioset_resize()
>> interface to the block layer and exposing it through a new bcache
>> sysfs attribute 'detached_pool_size'.
>> 
>> This allows us to keep the default value conservative (e.g., 4) to
>> avoid unnecessary memory overhead, while giving users the flexibility
>> to tune the emergency reserves based on their specific hardware and
>> workload requirements.
>> 
>> The patch is attached below. Does this look like a reasonable
>> compromise?
> 
> Guys, just stop. 4 is fine. Take a look at the default biosets and
> what reserve amount they use. I'd recommend you do some testing and
> check how often the reserves are _actually_ used, and once you do
> that, then you'll see why this isn't necessary at all.
> 
> I thought the idea was to make some progress on getting this fixed.
> Let's please do that and get it queued.

Yes, let’s get the fix in firstly.

Thanks.


Coly Li