From: Christoph Hellwig <hch@lst.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Damien Le Moal <dlemoal@kernel.org>,
Yu Kuai <yukuai1@huaweicloud.com>, Ming Lei <ming.lei@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] block: Make __submit_bio_noacct() preserve the bio submission order
Date: Fri, 16 May 2025 06:47:54 +0200 [thread overview]
Message-ID: <20250516044754.GA12964@lst.de> (raw)
In-Reply-To: <20250514202937.2058598-2-bvanassche@acm.org>
On Wed, May 14, 2025 at 01:29:36PM -0700, Bart Van Assche wrote:
> /*
> * Now assemble so we handle the lowest level first.
> */
> + bio_list_on_stack[0] = bio_list_on_stack[1];
> bio_list_merge(&bio_list_on_stack[0], &lower);
> bio_list_merge(&bio_list_on_stack[0], &same);
> - bio_list_merge(&bio_list_on_stack[0], &bio_list_on_stack[1]);
If I read this code correctly, this means that we no keep processing bios
that already were on bio_list_on_stack[0] and the beginning of the loop
in the next iteration(s) instead of finishing off the ones created by
this iteration, which could lead to exhaustion of resources like mempool.
Note that this is a big if - the code is really hard to read, it should
really grow a data structure for the on-stack list that has named members
for both lists instead of the array magic.. :(
I'm still trying to understand your problem given that it wasn't
described much. What I could think it is that bio_split_to_limits through
bio_submit_split first re-submits the remainder bio using
submit_bio_noacct, which the above should place on the same list and then
later the stacking block drivers also submit the bio split off at the
beginning, unlike blk-mq drivers that process it directly. But given
that this resubmission should be on the lower list above I don't
see how it causes problems.
next prev parent reply other threads:[~2025-05-16 4:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250514202937.2058598-1-bvanassche@acm.org>
2025-05-14 20:29 ` [PATCH 1/2] block: Make __submit_bio_noacct() preserve the bio submission order Bart Van Assche
2025-05-15 7:19 ` Niklas Cassel
2025-05-15 15:58 ` Bart Van Assche
2025-05-16 4:47 ` Christoph Hellwig [this message]
2025-05-19 22:12 ` Bart Van Assche
2025-05-20 13:56 ` Christoph Hellwig
2025-05-20 18:09 ` Bart Van Assche
2025-05-21 5:53 ` Christoph Hellwig
2025-05-21 21:18 ` Bart Van Assche
2025-05-23 4:21 ` Christoph Hellwig
2025-05-14 20:29 ` [PATCH 2/2] block: Fix a deadlock related freezing zoned storage devices Bart Van Assche
2025-05-16 4:51 ` Christoph Hellwig
2025-05-19 22:22 ` Bart Van Assche
2025-05-20 13:57 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250516044754.GA12964@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=dlemoal@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yukuai1@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox