Re: [PATCH v2] dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement

Robin Murphy
2026-04-01T15:26:24Z

On 2026-04-01 2:25 pm, Andy Shevchenko wrote:
> On Wed, Apr 1, 2026 at 3:11 PM Robin Murphy <robin.murphy@arm.com> wrote:
>> On 2026-03-30 8:44 am, Marek Szyprowski wrote:
>>> On 27.03.2026 13:41, Mikhail Gavrilov wrote:
>
> ...
>
>> TBH I'd be inclined to have CONFIG_DMA_DEBUG raise ARCH_DMA_MINALIGN as
>> appropriate such that genuine false-positives can't happen, rather than
>> effectively defeat the whole check,
>
> I dunno if you read v1 thread, where I proposed to unroll the check
> and use pr_debug_once() for the cases which we expect not to panic,
> but would be good to have a track of.

I had not seen v1, as I took the last 3 days off and hadn't got that far
up my inbox yet - I guess it's at least reassuring to have reached
similar conclusions independently :)

The fundamental issue here is that dma-debug doesn't realistically have
a way to know whether the thing being mapped is intentionally a whole
dedicated kmalloc allocation - where we can trust SLUB (and
DMA_BOUNCE_UNALIGNED_KMALLOC if appropriate) to do the right thing
across different systems - or just something which might happen to line
up by coincidence on someone's development machine, but for portability
they definitely do still need to take explicit care about (e.g. struct
devres::data).

Certainly some milder and/or opt-in reporting of
potential-false-positive overlaps wouldn't be a terrible idea, if
someone wants to have a crack at it.

Thanks,
Robin.