From: Christoph Hellwig <hch@lst.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
Justin Sanders <justin@coraid.com>,
Denis Efremov <efremov@linux.com>,
Josef Bacik <josef@toxicpanda.com>,
Geoff Levand <geoff@infradead.org>,
Ilya Dryomov <idryomov@gmail.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>, Ming Lei <ming.lei@redhat.com>,
Maxim Levitsky <maximlevitsky@gmail.com>,
Alex Dubov <oakad@yahoo.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Vineeth Vijayan <vneethv@linux.ibm.com>,
linux-block@vger.kernel.org, nbd@other.debian.org,
ceph-devel@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-s390@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 17/17] mmc: pass queue_limits to blk_mq_alloc_disk
Date: Wed, 21 Feb 2024 06:44:24 +0100 [thread overview]
Message-ID: <20240221054424.GA12033@lst.de> (raw)
In-Reply-To: <CAMuHMdWV4nWQHUpBKM2gHWeH9j9c0Di4bhg+F4-SAPEAmZuNSA@mail.gmail.com>
On Tue, Feb 20, 2024 at 11:01:05PM +0100, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Thu, Feb 15, 2024 at 9:16 AM Christoph Hellwig <hch@lst.de> wrote:
> > Pass the queue limit set at initialization time directly to
> > blk_mq_alloc_disk instead of updating it right after the allocation.
> >
> > This requires refactoring the code a bit so that what was mmc_setup_queue
> > before also allocates the gendisk now and actually sets all limits.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Thanks for your patch, which is now commit 616f876617927732 ("mmc: pass
> queue_limits to blk_mq_alloc_disk") in block/for-next.
>
> I have bisected the following failure on White-Hawk (also seen on
> other R-Car Gen3/4 systems) to this commit:
>
> renesas_sdhi_internal_dmac ee140000.mmc: mmc0 base at
> 0x00000000ee140000, max clock rate 200 MHz
> mmc0: new HS400 MMC card at address 0001
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 20 at block/blk-settings.c:202
> blk_validate_limits+0x12c/0x1e0
This is:
if (lim->virt_boundary_mask) {
if (WARN_ON_ONCE(lim->max_segment_size &&
lim->max_segment_size != UINT_MAX))
return -EINVAL;
so we end up here with both a virt_boundary_mask and a
max_segment_size set, which is rather bogus. I think the
problem is the order of check in the core blk_validate_limits
that artificially causes this. Can you try this patch?
diff --git a/block/blk-settings.c b/block/blk-settings.c
index c4406aacc0efc6..2120b6f9fef8ea 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -182,16 +182,6 @@ static int blk_validate_limits(struct queue_limits *lim)
if (WARN_ON_ONCE(lim->seg_boundary_mask < PAGE_SIZE - 1))
return -EINVAL;
- /*
- * The maximum segment size has an odd historic 64k default that
- * drivers probably should override. Just like the I/O size we
- * require drivers to at least handle a full page per segment.
- */
- if (!lim->max_segment_size)
- lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
- if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
- return -EINVAL;
-
/*
* Devices that require a virtual boundary do not support scatter/gather
* I/O natively, but instead require a descriptor list entry for each
@@ -203,6 +193,16 @@ static int blk_validate_limits(struct queue_limits *lim)
lim->max_segment_size != UINT_MAX))
return -EINVAL;
lim->max_segment_size = UINT_MAX;
+ } else {
+ /*
+ * The maximum segment size has an odd historic 64k default that
+ * drivers probably should override. Just like the I/O size we
+ * require drivers to at least handle a full page per segment.
+ */
+ if (!lim->max_segment_size)
+ lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
+ if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
+ return -EINVAL;
}
/*
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
Justin Sanders <justin@coraid.com>,
Denis Efremov <efremov@linux.com>,
Josef Bacik <josef@toxicpanda.com>,
Geoff Levand <geoff@infradead.org>,
Ilya Dryomov <idryomov@gmail.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>, Ming Lei <ming.lei@redhat.com>,
Maxim Levitsky <maximlevitsky@gmail.com>,
Alex Dubov <oakad@yahoo.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Vineeth Vijayan <vneethv@linux.ibm.com>,
linux-block@vger.kernel.org, nbd@other.debian.org,
ceph-devel@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-s390@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 17/17] mmc: pass queue_limits to blk_mq_alloc_disk
Date: Wed, 21 Feb 2024 06:44:24 +0100 [thread overview]
Message-ID: <20240221054424.GA12033@lst.de> (raw)
In-Reply-To: <CAMuHMdWV4nWQHUpBKM2gHWeH9j9c0Di4bhg+F4-SAPEAmZuNSA@mail.gmail.com>
On Tue, Feb 20, 2024 at 11:01:05PM +0100, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Thu, Feb 15, 2024 at 9:16 AM Christoph Hellwig <hch@lst.de> wrote:
> > Pass the queue limit set at initialization time directly to
> > blk_mq_alloc_disk instead of updating it right after the allocation.
> >
> > This requires refactoring the code a bit so that what was mmc_setup_queue
> > before also allocates the gendisk now and actually sets all limits.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Thanks for your patch, which is now commit 616f876617927732 ("mmc: pass
> queue_limits to blk_mq_alloc_disk") in block/for-next.
>
> I have bisected the following failure on White-Hawk (also seen on
> other R-Car Gen3/4 systems) to this commit:
>
> renesas_sdhi_internal_dmac ee140000.mmc: mmc0 base at
> 0x00000000ee140000, max clock rate 200 MHz
> mmc0: new HS400 MMC card at address 0001
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 20 at block/blk-settings.c:202
> blk_validate_limits+0x12c/0x1e0
This is:
if (lim->virt_boundary_mask) {
if (WARN_ON_ONCE(lim->max_segment_size &&
lim->max_segment_size != UINT_MAX))
return -EINVAL;
so we end up here with both a virt_boundary_mask and a
max_segment_size set, which is rather bogus. I think the
problem is the order of check in the core blk_validate_limits
that artificially causes this. Can you try this patch?
diff --git a/block/blk-settings.c b/block/blk-settings.c
index c4406aacc0efc6..2120b6f9fef8ea 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -182,16 +182,6 @@ static int blk_validate_limits(struct queue_limits *lim)
if (WARN_ON_ONCE(lim->seg_boundary_mask < PAGE_SIZE - 1))
return -EINVAL;
- /*
- * The maximum segment size has an odd historic 64k default that
- * drivers probably should override. Just like the I/O size we
- * require drivers to at least handle a full page per segment.
- */
- if (!lim->max_segment_size)
- lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
- if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
- return -EINVAL;
-
/*
* Devices that require a virtual boundary do not support scatter/gather
* I/O natively, but instead require a descriptor list entry for each
@@ -203,6 +193,16 @@ static int blk_validate_limits(struct queue_limits *lim)
lim->max_segment_size != UINT_MAX))
return -EINVAL;
lim->max_segment_size = UINT_MAX;
+ } else {
+ /*
+ * The maximum segment size has an odd historic 64k default that
+ * drivers probably should override. Just like the I/O size we
+ * require drivers to at least handle a full page per segment.
+ */
+ if (!lim->max_segment_size)
+ lim->max_segment_size = BLK_MAX_SEGMENT_SIZE;
+ if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
+ return -EINVAL;
}
/*
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-02-21 5:44 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 7:02 pass queue_limits to blk_mq_alloc_disk for simple drivers Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 01/17] ubd: pass queue_limits to blk_mq_alloc_disk Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 02/17] aoe: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 03/17] floppy: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-19 6:39 ` Denis Efremov (Oracle)
2024-02-15 7:02 ` [PATCH 04/17] mtip: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 05/17] nbd: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 06/17] ps3disk: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 07/17] rbd: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-20 11:18 ` Ilya Dryomov
2024-02-20 11:18 ` Ilya Dryomov
2024-02-15 7:02 ` [PATCH 08/17] rnbd-clt: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-16 7:49 ` Jinpu Wang
2024-02-16 7:49 ` Jinpu Wang
2024-02-15 7:02 ` [PATCH 09/17] sunvdc: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 10/17] gdrom: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 11/17] ms_block: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 12/17] mspro_block: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 13/17] mtd_blkdevs: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 14/17] ubiblock: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-18 2:33 ` Zhihao Cheng
2024-02-18 2:33 ` Zhihao Cheng
2024-02-15 7:02 ` [PATCH 15/17] scm_blk: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:02 ` [PATCH 16/17] ublk: " Christoph Hellwig
2024-02-15 7:02 ` Christoph Hellwig
2024-02-15 7:03 ` [PATCH 17/17] mmc: " Christoph Hellwig
2024-02-15 7:03 ` Christoph Hellwig
2024-02-15 16:40 ` Ulf Hansson
2024-02-15 16:40 ` Ulf Hansson
2024-02-15 16:49 ` Christoph Hellwig
2024-02-15 16:49 ` Christoph Hellwig
2024-02-15 16:53 ` Ulf Hansson
2024-02-15 16:53 ` Ulf Hansson
2024-02-20 22:01 ` Geert Uytterhoeven
2024-02-20 22:01 ` Geert Uytterhoeven
2024-02-20 22:14 ` Geert Uytterhoeven
2024-02-20 22:14 ` Geert Uytterhoeven
2024-02-21 5:44 ` Christoph Hellwig [this message]
2024-02-21 5:44 ` Christoph Hellwig
2024-02-21 9:37 ` Geert Uytterhoeven
2024-02-21 9:37 ` Geert Uytterhoeven
2024-06-27 9:43 ` Jon Hunter
2024-06-27 9:43 ` Jon Hunter
2024-06-27 9:49 ` Christoph Hellwig
2024-06-27 9:49 ` Christoph Hellwig
2024-06-27 9:58 ` Jon Hunter
2024-06-27 9:58 ` Jon Hunter
2024-06-27 11:19 ` Christoph Hellwig
2024-06-27 12:30 ` Jon Hunter
2024-06-27 12:44 ` Christoph Hellwig
2024-06-27 13:09 ` Jon Hunter
2024-06-27 13:44 ` Adrian Hunter
2024-06-27 14:47 ` Christoph Hellwig
2024-06-28 8:06 ` Adrian Hunter
2024-06-28 12:32 ` Christoph Hellwig
2024-06-28 12:37 ` Adrian Hunter
2024-06-28 12:51 ` Christoph Hellwig
2024-06-28 13:45 ` Adrian Hunter
2024-07-03 8:22 ` Jon Hunter
2024-07-04 7:24 ` Christoph Hellwig
2024-06-28 9:05 ` Jon Hunter
2024-02-20 13:22 ` pass queue_limits to blk_mq_alloc_disk for simple drivers Jens Axboe
2024-02-20 13:22 ` Jens Axboe
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=20240221054424.GA12033@lst.de \
--to=hch@lst.de \
--cc=anton.ivanov@cambridgegreys.com \
--cc=axboe@kernel.dk \
--cc=ceph-devel@vger.kernel.org \
--cc=efremov@linux.com \
--cc=geert@linux-m68k.org \
--cc=geoff@infradead.org \
--cc=haris.iqbal@ionos.com \
--cc=idryomov@gmail.com \
--cc=jinpu.wang@ionos.com \
--cc=johannes@sipsolutions.net \
--cc=josef@toxicpanda.com \
--cc=justin@coraid.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=ming.lei@redhat.com \
--cc=miquel.raynal@bootlin.com \
--cc=nbd@other.debian.org \
--cc=oakad@yahoo.com \
--cc=richard@nod.at \
--cc=ulf.hansson@linaro.org \
--cc=vigneshr@ti.com \
--cc=vneethv@linux.ibm.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 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.