Re: [PATCH v4] scsi: sas: skip opt_sectors when DMA reports no real optimization hint

[Damien Le Moal <dlemoal@kernel.org>]

On 3/20/26 05:43, Ionut Nechita (Wind River) wrote:
> On Wed, 19 Mar 2026 11:07:00 +0000, Damien Le Moal wrote:
>> Why return 0 ? This is a valid case, so this should get through the
>> alignment below.
> 
> Hi Damien,
> 
> Thanks for the review.
> 
> The opt == max case is specifically the bug this patch fixes.
> 
> When the IOMMU is disabled or in passthrough mode and no DMA ops
> provide an opt_mapping_size callback, dma_opt_mapping_size() falls
> back to min(SIZE_MAX, dma_max_mapping_size()), which equals
> dma_max_mapping_size().  So opt == max.
> 
> If we let that value through, rounddown_pow_of_two() produces a
> huge power-of-two, and min_t() caps it at max_sectors (32767).
> That gives opt_sectors = 32767, which is exactly the bogus value
> that breaks mkfs.xfs:
> 
>   swidth = 16773120 / 4096 = 4095
>   sunit  = 8192 / 4096     = 2
>   4095 % 2 != 0  ->  "SB stripe unit sanity check failed"
> 
> The key insight (from Robin Murphy's v1 review) is that when no
> backend provides a real optimization constraint, the DMA core
> returns the largest efficient size == the largest size.  That is
> correct DMA semantics, but it means opt == max signals "no
> preference", not "the optimal size happens to equal the maximum".
> 
> Returning 0 in that case means "no preference", which leaves
> opt_sectors at 0 and lets the disk's own geometry (or lack
> thereof) determine the I/O size.

Thanks for re-explaining this.

The code needs to have all this explanation as comment so that we do not trip on
this again.

> 
> Regarding the Cc list: noted, I will trim it for v5 if needed.
> 
> Thanks,
> Ionut


-- 
Damien Le Moal
Western Digital Research