0

I have a kernel list that is accessible by both ISR (top half) and bottom half (workqueue in my case). Originally I was using spin_lock_irqsave()/spin_unlock_irqstore() to disable interrupts inside both ISR and bottom half.

The program works fine except a warning because I am calling dma_alloc_coherent() inside spin_lock_irqsave()/spin_lock_irqstore(). I have checked the code looks like this function is not supposed to be called when interrupt is disabled... After switching to use spin_lock() inside workqueue but keep spin_lock_irqsave() inside ISR and the warning goes away...

I have to use spin_lock() inside the workqueue because limitation of the project. So is this program really safe after the compromise?

PS: I was using GFP_KERNEL with dma_alloc_coherent() earlier, not sure if GFP_ATOMIC is the right flag to use instead?

luke
  • 400
  • 6
  • 15
  • Whichever function - `spin_lock` or `spin_lock_irqsave` - is called for acquire a spinlock, you **shouldn't sleep** while holding it. See e.g. this question: https://stackoverflow.com/questions/4752031/why-cant-you-sleep-while-holding-spinlock. – Tsyvarev Dec 28 '18 at 07:32
  • Definitely using GFP_KERNEL with dma_alloc_coherent() inside a spinlock is wrong. I'm not sure why the warning goes away when you used it without disabling interrupts. – Raman Dec 28 '18 at 14:51
  • Thanks for the input. So I should use GFP_ATOMIC to prevent dma_alloc_coherent() from sleeping inside the spin lock... however the warning would still be there had I used spin_lock_irqsave() because after calling dma_alloc_coherent() I would call dma_free_coherent() (sorry for confusion in the post). and dma_free_coherent() throws a warning because interrupt is disabled... But the problem of using spin_lock() without interrupt disabled looks like a problem to me... Any idea what might be a better solution here? – luke Dec 29 '18 at 06:05

0 Answers0