Re: [PATCH 02/24] ARM: l2c: Serialize device reads with cache maintenance when requested

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm: unbounded IRQ latency in L2C_IO_LOCKED_RANGE_OP wrapper
--

commit 200bbafd893402f8ddb823a9bb579e0fb79d8e62
Author: Navid Ghahremani <ghahramani.navid@gmail.com>

ARM: l2c: Serialize device reads with cache maintenance when requested

This commit introduces an optional lock to serialize device reads with L2C-310
maintenance operations. It works around an interconnect deadlock on some SoCs by
taking a spinlock during outer cache range operations and device reads.

> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 470867160076f..35cc2eaf85a60 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c

[ ... ]

> +#define L2C_IO_LOCKED_RANGE_OP(op)					\
> +static void l2c_io_locked_##op(unsigned long start, unsigned long end)	\
> +{									\
> +	unsigned long flags;						\
> +									\
> +	raw_spin_lock_irqsave(&l2x0_io_lock, flags);			\
> +	l2x0_io_fns.op(start, end);					\
> +	raw_spin_unlock_irqrestore(&l2x0_io_lock, flags);		\
> +}
> +
> +L2C_IO_LOCKED_RANGE_OP(inv_range)
> +L2C_IO_LOCKED_RANGE_OP(clean_range)
> +L2C_IO_LOCKED_RANGE_OP(flush_range)

[Severity: High]
Does this introduce unbounded interrupt latency during large outer cache range
operations?

By wrapping the entire O(N) range operation in a single
raw_spin_lock_irqsave(), local interrupts are kept disabled for the duration
of the operation.

Standard L2C range loops natively execute with interrupts fully enabled, as seen
in __l2c210_op_pa_range():

	while (start < end) {
		writel_relaxed(start, reg);
		start += CACHE_LINE_SIZE;
	}

For functions that do take a lock internally, like
l2c310_flush_range_erratum(), they explicitly bound interrupt latency by
yielding every 4KB:

		if (blk_end < end) {
			raw_spin_unlock_irqrestore(lock, flags);
			raw_spin_lock_irqsave(lock, flags);
		}

Wrapping the call defeats this latency bound completely. Could this cause
dropped hardware events, audio dropouts, or watchdog timeouts when performing
DMA mapping on large buffers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010130024.177503-1-ghahramani.navid@gmail.com?part=2