On Tue, Feb 9, 2021 at 11:24 AM luojiaxing <luojiaxing@xxxxxxxxxx> wrote: > On 2021/2/8 21:28, Andy Shevchenko wrote: > > On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@xxxxxxxxxx> wrote: > >> Sorry, my operation error causes a patch missing from this patch set. I > >> re-send the patch set. Please check the new one. > > What is the new one?! You have to give proper versioning and change > > log for your series. > > sure, I will send a new one later, but let me answer your question first. > > >> On 2021/2/8 16:56, Luo Jiaxing wrote: > >>> There is no need to use API with _irqsave in hard IRQ handler, So replace > >>> those with spin_lock. > > How do you know that another CPU in the system can't serve the The keyword here is: *another*. > > following interrupt from the hardware at the same time? > > Yes, I have some question before. > > There are some similar discussion here, please take a look, Song baohua > explained it more professionally. > > https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@xxxxxxxxxxxxx/ > > Here are some excerpts from the discussion: > > I think the code disabling irq in hardIRQ is simply wrong. Why? > Since this commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > genirq: Run irq handlers with interrupts disabled > > interrupt handlers are definitely running in a irq-disabled context > unless irq handlers enable them explicitly in the handler to permit > other interrupts. This doesn't explain any changes in the behaviour on SMP. IRQ line can be disabled on a few stages: a) on the source (IP that generates an event) b) on IRQ router / controller c) on CPU side The commit above is discussing (rightfully!) the problem when all interrupts are being served by a *single* core. Nobody prevents them from being served by *different* cores simultaneously. Also, see [1]. [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html -- With Best Regards, Andy Shevchenko