Linux network filesystem support library
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Keith Busch <kbusch@kernel.org>
Cc: dhowells@redhat.com, Christoph Hellwig <hch@lst.de>,
	Jens Axboe <axboe@kernel.dk>, Hannes Reinecke <hare@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Paulo Alcantara <pc@manguebit.org>,
	netfs@lists.linux.dev, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] block: Fix start and length check added to iov_iter_extract_bvecs()
Date: Sat, 05 Sep 2026 17:26:40 +0100	[thread overview]
Message-ID: <1183138.1788625600@warthog.procyon.org.uk> (raw)
In-Reply-To: <apsP3Hvlw-fpd6uF@kbusch-mbp>

Keith Busch <kbusch@kernel.org> wrote:

> If a block device behind an RDMA NIC really wants to DMA a single byte
> at a time, we can't describe that capability today. That would require a
> 0 mask, which is currently treated as "unset" and overridden with a
> default 512b mask.

The thing is, Christoph said:

    Massage __bio_iov_iter_get_pages so that it doesn't need the bio, and
    move it to lib/iov_iter.c so that it can be used by block code for
    other things than filling a bio and by other subsystems like netfs.

but unless it can have a 1-byte alignment, it's not actually much use for
netfslib (I have to be able to support "unbuffered writes", which are almost
exactly like DIO writes but without alignment restrictions).

Do block devices really need an aligned "start memory address" or just an
aligned "start file position" (whatever that means for a blockdev).

David


      reply	other threads:[~2026-09-05 16:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 18:18 [PATCH] block: Fix start and length check added to iov_iter_extract_bvecs() David Howells
2026-08-26 18:34 ` Keith Busch
2026-08-26 19:24   ` David Howells
2026-08-26 19:47     ` Keith Busch
2026-08-26 20:23       ` David Howells
2026-08-26 19:49   ` David Howells
2026-08-26 20:02     ` Keith Busch
2026-08-26 20:46 ` [PATCH v2] " David Howells
2026-08-26 20:52   ` Keith Busch
2026-08-26 20:54   ` David Howells
2026-09-02 11:27   ` Christoph Hellwig
2026-09-04  9:42     ` David Howells
2026-09-04 18:37       ` Keith Busch
2026-09-05 16:26         ` David Howells [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=1183138.1788625600@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=hare@kernel.org \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=pc@manguebit.org \
    --cc=viro@zeniv.linux.org.uk \
    /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