Re: [PATCH] dmaengine: altera-msgdma: fix descriptors freeing logic

[Olivier Dautricourt]

Hi Eric,

On Fri, Sep 22, 2023 at 09:49:59AM +0200, Eric Schwarz wrote:
> Hello Olivier,
> 
> > > Am 20.09.2023 um 21:58 schrieb Olivier Dautricourt:
> > > > Sparse complains because we first take the lock in msgdma_tasklet -> move
> > > > locking to msgdma_chan_desc_cleanup.
> > > > In consequence, move calling of msgdma_chan_desc_cleanup outside of the
> > > > critical section of function msgdma_tasklet.
> > > > 
> > > > Use spin_unlock_irqsave/restore instead of just spinlock/unlock to keep
> > > > state of irqs while executing the callbacks.
> > > 
> > > What about the locking in the IRQ handler msgdma_irq_handler() itself? -
> > > Shouldn't spin_unlock_irqsave/restore() be used there as well instead of
> > > just spinlock/unlock()?
> > 
> > IMO no:
> > It is covered by [1]("Locking Between Hard IRQ and Softirqs/Tasklets")
> > The irq handler cannot be preempted by the tasklet, so the
> > spin_lock/unlock version is ok. However the tasklet could be interrupted
> > by the Hard IRQ hence the disabling of irqs with save/restore when
> > entering critical section.
> > 
> > It should not be needed to keep interrupts locally disabled while invoking
> > callbacks, will add this to the commit description.
> > 
> > [1] https://www.kernel.org/doc/Documentation/kernel-hacking/locking.rst
> 
> Thanks for the link. I have read differently here [2] w/ special emphasis on
> "Lesson 3: spinlocks revisited.".
> 
> [2] https://www.kernel.org/doc/Documentation/locking/spinlocks.txt
> 

This chapter [2] says that our code must use irq versions of spin_lock
because our handler does indeed play with the lock. However this
requirement does not apply to the irq handler itself, as we know that the
interrupt line is disabled during the execution of the handler (and our
handler is not shared with another irq).

Kr,
Olivier

> Cheers
> Eric