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

[Mike Snitzer <snitzer@kernel.org>]

On Tue, Nov 03, 2026 at 10:31:27AM -0700, Keith Busch wrote:
> 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.

DM devices have the ability to change limits really well, both in DM
core and the individual DM targets using .io_hints hook in their
target_type struct.  Mikulas knows what is needed for DM.

Mike