From: Christoph Hellwig <hch@infradead.org>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
Keith Busch <kbusch@kernel.org>,
stable@vger.kernel.org, Henry Hu <huhai@kylinos.cn>
Subject: Re: [PATCH] blk-mq: set RQF_USE_SCHED when the operation is known
Date: Tue, 22 Sep 2026 05:48:36 -0700 [thread overview]
Message-ID: <arJ5JISABWd7uahn@infradead.org> (raw)
In-Reply-To: <20260921212624.1942234-1-kbusch@meta.com>
On Mon, Sep 21, 2026 at 02:26:24PM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> The cached requests are allocated for one operation but can be handed
> out for another. A passthrough command has RQF_USE_SCHED cleared, so
> using those flags for a subsequent read/write bio will insert it into
> the scheduler without ->prepare_request() and frees it without
> ->finish_request(). For kyber, this leaks the domain token acquired at
> dispatch and stalls the queue.
>
> Don't set RQF_USE_SCHED based on the first operation the batch happened
> to be allocated for. Instead, set it after the request is claimed by an
> operation.
This looks generally good, but also a bit hard to follow.
Notes:
- mq-deadline refers to blk_mq_rq_ctx_init in a comment that needs
to be updated or removed.
- blk_mq_rq_time_init is always called right next to
blk_mq_set_rq_sched. Should these be comined in a single late
init helper?
- AFAICS the op_is_flush check removal is enabled by this, but not
required, so maybe move it in a well-documened follow on patch?
prev parent reply other threads:[~2026-09-22 12:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 21:26 [PATCH] blk-mq: set RQF_USE_SCHED when the operation is known Keith Busch
2026-09-22 5:48 ` Hannes Reinecke
2026-09-22 12:48 ` Christoph Hellwig [this message]
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=arJ5JISABWd7uahn@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=huhai@kylinos.cn \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.