From: Pavel Begunkov <asml.silence@gmail.com>
To: Keith Busch <kbusch@meta.com>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
axboe@kernel.dk
Cc: hch@lst.de, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 0/2] block, nvme: minor fixes to dma-buf support
Date: Tue, 27 Oct 2026 14:28:59 +0000 [thread overview]
Message-ID: <08e772c7-5e32-4e0c-b161-49ba970c6595@gmail.com> (raw)
In-Reply-To: <20261021184658.644645-1-kbusch@meta.com>
On 10/21/26 19:46, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> Just a couple minor fixes. I wish I could say I caught the first one
> myself, but no, I prompted an LLM to look at it.
>
> I am assuming changing the bi_offset type to accomodate large offsets
> isn't acceptable as the bvec_iter's size appears to be packed to be
> small. I think there's a path to accepting larger offsets through
> bi_idx, but the patch proposed here is a safer quick fix.
It'd be curious to hear how you want to pack it. On the same note,
we'll eventually also need support vectored readv/writev and very
likely have the same problem. E.g. we'd either need to keep map in
another field (perhaps in bio only), or demormalising data and
keeping an array of {map,off,len}.
> Keith Busch (2):
> block: reject dma-bufs larger than 4GiB
> nvme-pci: detach dma-bufs only on removal
>
> block/fops.c | 4 ++++
> drivers/nvme/host/pci.c | 4 +---
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
--
Pavel Begunkov
prev parent reply other threads:[~2026-10-27 14:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 18:46 [PATCH 0/2] block, nvme: minor fixes to dma-buf support Keith Busch
2026-10-21 18:46 ` [PATCH 1/2] block: reject dma-bufs larger than 4GiB Keith Busch
2026-10-23 17:52 ` Pavel Begunkov
2026-10-27 13:38 ` Pavel Begunkov
2026-10-21 18:46 ` [PATCH 2/2] nvme-pci: detach dma-bufs only on removal Keith Busch
2026-10-22 12:41 ` [PATCH 0/2] block, nvme: minor fixes to dma-buf support Jens Axboe
2026-10-27 14:28 ` Pavel Begunkov [this message]
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=08e772c7-5e32-4e0c-b161-49ba970c6595@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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