Re: Bug in add_dma_entry()'s debugging code

[Robin Murphy]

On 28/11/2023 4:34 pm, Andy Shevchenko wrote:
> On Tue, Nov 28, 2023 at 6:31 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> > On 28/11/2023 3:18 pm, Alan Stern wrote:
> > > On Tue, Nov 28, 2023 at 02:37:02PM +0100, Christoph Hellwig wrote:
>
> ...
>
> > > > The logical confcusion from that would be that IFF dma-debug is enabled on
> > > > any platform we need to set ARCH_DMA_MINALIGN to the cache line size.
> > >
> > > (IF, not IFF.)  And tell distributions that CONFIG_DMA_API_DEBUG is not
> > > meant for production systems but rather for kernel testing, right?
> >
> > Yikes, I'd hope that distros are heeding the warning that the Kconfig
> > calls out already. It's perhaps somewhat understated, as I'd describe
> > the performance impact to large modern systems with high-bandwidth I/O
> > as somewhere between "severe" and "crippling".
>
> Independently on the distros configurations the (false positive)
> message(s) will make difficult to debug the actual things, shouldn't
> we have our code robust in any case?

Sure, I have no objection to making dma-debug more robust and useful for 
its intended purpose, I was just commenting on the fact that any 
potential change in behaviour from this should be of less concern to 
distros than the significant change in behaviour that enabling it 
*already* poses (i.e. globally serialising DMA operations and doing 
inherently slow stuff in what are normally expected to be fast paths).

Thanks,
Robin.