From: "Richard W.M. Jones" <rjones@redhat.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>,
Jiri Jaburek <jjaburek@redhat.com>,
Christoph Hellwig <hch@lst.de>,
Bart Van Assche <bvanassche@acm.org>,
Damien Le Moal <dlemoal@kernel.org>,
Hannes Reinecke <hare@suse.de>,
Chaitanya Kulkarni <kch@nvidia.com>
Subject: Re: [PATCH] block: elevator: avoid to load iosched module from this disk
Date: Sat, 7 Sep 2024 08:35:22 +0100 [thread overview]
Message-ID: <20240907073522.GW1450@redhat.com> (raw)
In-Reply-To: <20240907014331.176152-1-ming.lei@redhat.com>
On Sat, Sep 07, 2024 at 09:43:31AM +0800, Ming Lei wrote:
> When switching io scheduler via sysfs, 'request_module' may be called
> if the specified scheduler doesn't exist.
>
> This was has deadlock risk because the module may be stored on FS behind
> our disk since request queue is frozen before switching its elevator.
>
> Fix it by returning -EDEADLK in case that the disk is claimed, which
> can be thought as one signal that the disk is mounted.
>
> Some distributions(Fedora) simulates the original kernel command line of
> 'elevator=foo' via 'echo foo > /sys/block/$DISK/queue/scheduler', and boot
> hang is triggered.
>
> Cc: Richard Jones <rjones@redhat.com>
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Cc: Jiri Jaburek <jjaburek@redhat.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
I'd suggest also:
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=219166
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Reported-by: Jiri Jaburek <jjaburek@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
So I have tested this patch and it does fix the issue, at the possible
cost that now setting the scheduler can fail:
+ for f in /sys/block/{h,s,ub,v}d*/queue/scheduler
+ echo noop
/init: line 109: echo: write error: Resource deadlock avoided
(I know I'm setting it to an impossible value here, but this could
also happen when setting it to a valid one.)
Since almost no one checks the result of 'echo foo > /sys/...' that
would probably mean that sometimes a desired setting is silently not
set.
Also I bisected this bug yesterday and found it was caused by (or,
more likely, exposed by):
commit af2814149883e2c1851866ea2afcd8eadc040f79
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Jun 17 08:04:38 2024 +0200
block: freeze the queue in queue_attr_store
queue_attr_store updates attributes used to control generating I/O, and
can cause malformed bios if changed with I/O in flight. Freeze the queue
in common code instead of adding it to almost every attribute.
Reverting this commit on top of git head also fixes the problem.
Why did this commit expose the problem?
Rich.
> ---
> block/elevator.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/block/elevator.c b/block/elevator.c
> index f13d552a32c8..2b0432f4ac33 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -676,6 +676,13 @@ void elevator_disable(struct request_queue *q)
> blk_mq_unfreeze_queue(q);
> }
>
> +static bool disk_is_claimed(struct gendisk *disk)
> +{
> + if (disk->part0->bd_holder)
> + return true;
> + return false;
> +}
> +
> /*
> * Switch this queue to the given IO scheduler.
> */
> @@ -699,6 +706,13 @@ static int elevator_change(struct request_queue *q, const char *elevator_name)
>
> e = elevator_find_get(q, elevator_name);
> if (!e) {
> + /*
> + * Try to avoid to load iosched module from FS behind our
> + * disk, otherwise deadlock may be triggered
> + */
> + if (disk_is_claimed(q->disk))
> + return -EDEADLK;
> +
> request_module("%s-iosched", elevator_name);
> e = elevator_find_get(q, elevator_name);
> if (!e)
> --
> 2.46.0
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
next prev parent reply other threads:[~2024-09-07 7:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-07 1:43 [PATCH] block: elevator: avoid to load iosched module from this disk Ming Lei
2024-09-07 7:35 ` Richard W.M. Jones [this message]
2024-09-07 7:58 ` Ming Lei
2024-09-07 9:04 ` Damien Le Moal
2024-09-07 9:48 ` Ming Lei
2024-09-07 10:02 ` Richard W.M. Jones
2024-09-07 10:07 ` Ming Lei
2024-09-07 10:36 ` Richard W.M. Jones
2024-09-07 11:01 ` Richard W.M. Jones
2024-09-07 11:02 ` Ming Lei
2024-09-07 11:14 ` Richard W.M. Jones
2024-09-08 0:02 ` Damien Le Moal
2024-09-09 1:00 ` Ming Lei
2024-09-09 1:01 ` Ming Lei
2024-09-07 9:53 ` Richard W.M. Jones
2024-09-07 13:50 ` Jens Axboe
2024-09-09 1:24 ` Ming Lei
2024-09-09 1:56 ` Damien Le Moal
2024-09-09 1:59 ` Damien Le Moal
2024-09-09 2:16 ` Ming Lei
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=20240907073522.GW1450@redhat.com \
--to=rjones@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=dlemoal@kernel.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jjaburek@redhat.com \
--cc=jmoyer@redhat.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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;
as well as URLs for NNTP newsgroup(s).