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 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.