On 11/19/25 12:58 AM, Christoph Hellwig wrote: > On Tue, Nov 18, 2025 at 10:10:33PM -0800, Bart Van Assche wrote: >> Is the following deadlock inherent to this approach? >> - Several bios are present on zwplug->bio_list and these bios cannot be >> submitted because their starting offset is past the write pointer. >> - No new bios can be allocated because all memory is in use. >> - A deadlock occurs because none of the queued bios can be submitted >> and no new bio can be allocated. > > This can if the number of in-flight bios is larger than bio mempool > reserve. Which is real, but we also have this in various other > submitters that hold bios to submit in a list. This suggests it is > mostly theoretical, but I'd still love to address it for all these > cases.
The default bio pool size is 2 entries, which is perfectly fine for the "normal" alloc-and-submit cases. But yes if you're doing a bunch of allocations before submitting, then it could certainly deadlock if the normal allocation fails and we end up sleeping in the mempool waiting for previous unsubmitted IO to finish. It's certainly a bit tricky to handle... But definitely something we should take a stab at, as it basically voids the forward progress guarantee and is surely something that will cause production workload deadlocks if REQ_ZWPLUG_UNORDERED is used. -- Jens Axboe
