From: Ming Lei <ming.lei@redhat.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Daniel Gomez <da.gomez@kernel.org>,
Paul Bunyan <pbunyan@redhat.com>, Yi Zhang <yi.zhang@redhat.com>,
John Garry <john.g.garry@oracle.com>,
Keith Busch <kbusch@kernel.org>,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH V4] block: make segment size limit workable for > 4K PAGE_SIZE
Date: Mon, 24 Feb 2025 09:48:04 +0800 [thread overview]
Message-ID: <Z7vP1MdHRQo0Kj7U@fedora> (raw)
In-Reply-To: <Z7vDnAtt9K14pZMz@bombadil.infradead.org>
On Sun, Feb 23, 2025 at 04:55:56PM -0800, Luis Chamberlain wrote:
> On Fri, Feb 21, 2025 at 12:12:44PM -0800, Luis Chamberlain wrote:
> > WARNING: CPU: 2 PID: 397 at block/blk-settings.c:339 blk_validate_limits+0x364/0x3c0
> > Modules linked in: mmc_block(+) rpmb_core crct10dif_ce ghash_ce sha2_ce dw_mmc_bluefield sha256_arm64 dw_mmc_pltfm sha1_ce dw_mmc mmc_core nfit i2c_mlxbf sbsa_gwdt gpio_mlxbf2
> > f_tmfifo dm_mirror dm_region_hash dm_log dm_mod
> > CPU: 2 UID: 0 PID: 397 Comm: (udev-worker) Not tainted 6.12.0-39.el10.aarch64+64k #1
> > Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.5.1-1-g4078432 Jan 28 2021
> > ng pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : blk_validate_limits+0x364/0x3c0
> > p.service
> > lr : blk_set_default_limits+0x20/0x40
> > Setup...
> > sp : ffff80008688f2d0
> > x29: ffff80008688f2d0 x28: ffff000082acb600 x27: ffff80007bef02a8
> > x26: ffff80007bef0000 x25: ffff80008688f58e x24: ffff80008688f450
> > x23: ffff80008301b000 x22: 00000000ffffffff x21: ffff800082c39950
> > x20: 0000000000000000 x19: ffff0000930169e0 x18: 0000000000000014
> > x17: 00000000767472b1 x16: 0000000005a697e6 x15: 0000000002f42ca4
> > x11: 00000000de7f0111 x10: 000000005285b53a x9 : ffff800080752908
> > x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000200
> > x5 : 0000000000000000 x4 : 000000000000ffff x3 : 0000000000004000
> > x2 : 0000000000000200 x1 : 0000000000001000 x0 : ffff80008688f450
> > Call trace:
> > blk_validate_limits+0x364/0x3c0
> > blk_set_default_limits+0x20/0x40
> > blk_alloc_queue+0x84/0x240
> > blk_mq_alloc_queue+0x80/0x118
> > __blk_mq_alloc_disk+0x28/0x198
> > mmc_alloc_disk+0xe0/0x260 [mmc_block]
> > ...
> > mmcblk mmc0:0001: probe with driver mmcblk failed with error -22
>
> I'm left still a bit perplexed with one question still, this is a known
> issue now with using large page systems with smaller DMA max segment
> sized devices either eMMC and Exynos UFS, does your patch just fix the
> probe issue on eMMC?
Yes.
> What about functionality?
It works just fine, as you saw Paul's tested-by, or do you think there
are other areas not covered by this patch.
> What aspsect of Bart's
> series is now not needed?
You can see this single patch as Bart's next version because of block
layer's evolution.
>
> Bart's series were NACK'd as the changes were deemed too intrusive to
> maintain on the block layer, so I am curious what has changed here to
> enable eMMC.
Basically, the following patches help much on the progress:
commit 6aeb4f836480 ("block: remove bio_add_pc_page")
commit 02ee5d69e3ba ("block: remove blk_rq_bio_prep")
commit b7175e24d6ac ("block: add a dma mapping iterator")
They changes passthrough code path to use split, so Bart's original
change in passthrough part isn't necessary.
> Will 16k page size systems with Exynos UFS work now?
It is supposed to be true.
Thanks,
Ming
next prev parent reply other threads:[~2025-02-24 1:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 2:44 [PATCH V4] block: make segment size limit workable for > 4K PAGE_SIZE Ming Lei
2025-02-20 6:13 ` Christoph Hellwig
2025-02-20 11:38 ` Ming Lei
2025-02-21 20:12 ` Luis Chamberlain
2025-02-22 21:43 ` Daniel Gomez
2025-02-24 0:55 ` Luis Chamberlain
2025-02-24 1:48 ` Ming Lei [this message]
2025-02-22 21:52 ` Daniel Gomez
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=Z7vP1MdHRQo0Kj7U@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=da.gomez@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=pbunyan@redhat.com \
--cc=yi.zhang@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