All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Mike Snitzer <snitzer@kernel.org>, Keith Busch <kbusch@meta.com>,
	axboe@kernel.dk, dm-devel@lists.linux.dev, mpatocka@redhat.com,
	bmarzins@redhat.com, linux-block@vger.kernel.org
Subject: Re: [PATCH] block: let a stacking device inherit its members' DMA alignment
Date: Tue, 3 Nov 2026 10:31:27 -0700	[thread overview]
Message-ID: <auoab2ewQZGDpRi3@kbusch-mbp> (raw)
In-Reply-To: <aumxcHVjVonjs6OV@infradead.org>

On Tue, Nov 03, 2026 at 02:03:28AM -0800, Christoph Hellwig wrote:
> On Thu, Oct 22, 2026 at 01:01:10PM -0400, Mike Snitzer wrote:
> > On Thu, Jul 09, 2026 at 09:15:17AM -0700, Keith Busch wrote:
> > > From: Keith Busch <kbusch@kernel.org>
> > > 
> > > All device mappers that want to override the dma_alignment do so.
> 
> Don't start a patch description by quoting another mail.
> 
> > Direct I/O from memory every member accepts is therefore rejected at
> > the stacking device, and callers that check the advertised alignment
> > (for instance through STATX_DIOALIGN) fall back to buffered I/O.
> > 
> > Leave dma_alignment at zero in blk_set_stacking_limits() so that the
> > stacked value is the strictest of the members'.  blk_validate_limits()
> > still applies the SECTOR_SIZE - 1 default when nothing was stacked,
> > such as for a table with no devices.  Targets that process the data
> > themselves and need logical-block-aligned memory already set
> > dma_alignment in their io_hints (dm-crypt, dm-integrity, dm-verity,
> > dm-log-writes), and NVMe multipath sets its own.
> 
> Chances are very high that this will introduce bugs somewhere,
> as a lot of drivers are historically not ready to deal with lower
> alignments, and will creeat nasty exploitable bugs.
> 
> So you'll need to audit each driver that wants to relax this
> individually, and then override the value for them.  Alternatively
> we could start with 0 in the block layer, but then you need to
> lift the current setting into each caller first, and only remove
> them one-by-one with a commit per driver explaining why that is safe
> (and sensible).

I suppose it would be safer to have each stacking driver that can
tolerate lower alignment granularity explicitly override the limit to 0
to inherit whatever the stacking members require. For md-raid,
that's not too bad as it can set lim.dma_alignment = 0 in
raid0_set_limits() after md_init_stacking_limits(). But other device
mappers don't have a way to override it so I guess something has to
happen in dm_calculate_queue_limits() to allow this option.

  reply	other threads:[~2026-11-03 17:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 16:15 [PATCHv5 0/3] dm-crypt: finer grained memory alignment Keith Busch
2026-07-09 16:15 ` [PATCHv5 1/3] dm: initialize dma_alignment to 0 Keith Busch
2026-10-22 17:01   ` [PATCH] block: let a stacking device inherit its members' DMA alignment Mike Snitzer
2026-10-22 17:25     ` sashiko-bot
2026-10-23 15:41       ` Mike Snitzer
2026-10-23 20:47         ` Mikulas Patocka
2026-11-03 10:03     ` [PATCH] " Christoph Hellwig
2026-11-03 17:31       ` Keith Busch [this message]
2026-07-09 16:15 ` [PATCHv5 2/3] dm-crypt: handle memory allocation failures Keith Busch
2026-07-09 16:15 ` [PATCHv5 3/3] dm-crypt: allow unaligned bio_vecs for direct io Keith Busch
2026-07-11  0:54   ` Eric Biggers
2026-07-11  4:14     ` Keith Busch
2026-07-11  4:30       ` Eric Biggers
2026-07-13 18:54         ` Keith Busch

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=auoab2ewQZGDpRi3@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hch@infradead.org \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.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 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.