On Tue, May 31, 2022 at 3:00 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 2022-05-31 22:51, Rob Clark wrote: > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > Ratelimit the error msg to avoid flooding the console. > > > > Signed-off-by: Rob Clark <robdclark@xxxxxxxxxxxx> > > --- > > kernel/dma/debug.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c > > index f8ff598596b8..683966f0247b 100644 > > --- a/kernel/dma/debug.c > > +++ b/kernel/dma/debug.c > > @@ -564,7 +564,7 @@ static void add_dma_entry(struct dma_debug_entry *entry, unsigned long attrs) > > > > rc = active_cacheline_insert(entry); > > if (rc == -ENOMEM) { > > - pr_err("cacheline tracking ENOMEM, dma-debug disabled\n"); > > + pr_err_ratelimited("cacheline tracking ENOMEM, dma-debug disabled\n"); > > global_disable = true; > > Given that it's supposed to disable itself entirely if it ever gets > here, just how spammy is it exactly? um, quite.. tbf that was in the context of a WIP igt test for shrinker which was trying to cycle thru ~2x RAM size worth of GEM buffers on something like 72 threads. So it could just be threads that had gotten past the dma_debug_disabled() check already before global_disable was set to true? I guess this could be pr_err_once() instead, then? BR, -R > Thanks, > Robin. > > > } else if (rc == -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) { > > err_printk(entry->dev, entry,