On Mon, Jun 10, 2024 at 08:23:09PM +0200, Thomas Gleixner wrote: > On Mon, Jun 10 2024 at 02:30, Peng Liu wrote: > > handle_nested_irq() is supposed to be running inside the parent thread > > handler context. It per se has no dedicated kernel thread, thus shouldn't > > touch desc->threads_active. The parent kernel thread has already taken > > care of this. > > No it has not. The parent thread has marked itself in the parent threads > interrupt descriptor. > > How does that help synchronizing the nested interrupt, which has a > separate interrupt descriptor? Right, I never thought there would be more than one interrupt descriptors involved which is quite common. > > > Fixes: e2c12739ccf7 ("genirq: Prevent nested thread vs synchronize_hardirq() deadlock") > > Cc: stable@xxxxxxxxxxxxxxx > > There is nothing to fix. > > > Signed-off-by: Peng Liu <iwtbavbm@xxxxxxxxx> > > --- > > > > Despite of its correctness, I'm afraid the testing on my only PC can't > > cover the affected code path. So the patch may be totally -UNTESTED-. > > Which correctness? > > The change log of the commit you want to "fix" says: > > Remove the incorrect usage in the nested threaded interrupt case and > instead re-use the threads_active / wait_for_threads mechanism to > wait for nested threaded interrupts to complete. > > It's very clearly spelled out, no? Indeed, due to my ignorance, I never thought there might be more descriptors involved. Now think about it, I never really understood the meaning of the above change log. Thanks for your time and concise explanation. Peng > > Thanks, > > tglx