[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACzX3Atwuv5RNqk5vah8J3Ce0i6sZdF+Tmnbw1K9qpDLU9bXxQ@mail.gmail.com>
Date: Wed, 4 Jun 2025 05:04:50 +0530
From: Anuj gupta <anuj1072538@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Caleb Sander Mateos <csander@...estorage.com>, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: flip iter directions in blk_rq_integrity_map_user()
On Wed, Jun 4, 2025 at 12:24 AM Jens Axboe <axboe@...nel.dk> wrote:
>
> On 6/3/25 12:47 PM, Caleb Sander Mateos wrote:
> > blk_rq_integrity_map_user() creates the ubuf iter with ITER_DEST for
> > write-direction operations and ITER_SOURCE for read-direction ones.
> > This is backwards; writes use the user buffer as a source for metadata
> > and reads use it as a destination. Switch to the rq_data_dir() helper,
> > which maps writes to ITER_SOURCE (WRITE) and reads to ITER_DEST(READ).
>
> Was going to ask "how did this ever work without splats", but looks like
> a fairly recent change AND it's for integrity which isn't widely used.
> But it does show a gap in testing for sure.
>
Yes, you're absolutely right. blk_rq_integrity_map_user() is currently
only used by nvme-passthru, and Keith recently added a test for that
path [1].
As for the user block integrity interface in general — it’s been a bit
tricky to write generic tests so far, mostly because there's no way to
query the device's integrity capabilities from userspace. But that
should become much easier once we have support for that via an ioctl[2].
[1] https://lore.kernel.org/io-uring/20250416162802.3614051-1-kbusch@meta.com/
[2] https://lore.kernel.org/all/20250527104237.2928-1-anuj20.g@samsung.com/
Powered by blists - more mailing lists