Re: block: let a stacking device inherit its members' DMA alignment

[Mike Snitzer <snitzer@kernel.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).
> 

Yeap, important work needed outside of DM for sure.  Mikulas, after DM,
are you willing to do this mechanical audit/change to the block
subsystem in general? ;)

Mike