>> Just need to postpone schedule_work to the slave CPU exiting the NMI context. >> >> irq_work will only respond to handle schedule_work after exiting the current >> interrupt context. >> >> When the master CPU exits the interrupt context, other CPUs will naturally >> exit the NMI context, so there will be no deadlock. >> >> It is the call to input_register_handler() that forces us not to do the work >> from irq_work's hardirq callback. >> >> Therefore schedule another work in the irq_work and not do the job directly. > >This looks like it was copy and pasted from the e-mail thread without any >editing to make it make any sense. It not even formatted correctly (where are >the line breaks?). > >How about: > >We fix the problem by using irq_work to call schedule_work() instead of >calling it directly. irq_work is an NMI-safe deferred work framework that >performs the requested work from a hardirq context (usually an IPI but it can >be timer interrupt on some architectures). > >Note that we still need to a workqueue since we cannot resync the keyboard >state from the hardirq context provided by irq_work. >That must be done from task context for the calls into the input subystem. >Hence we must defer the work twice. First to safely switch from the debug trap >(NMI-like context) to hardirq and then, secondly, to get from hardirq to the >system workqueue.
I apologize for my poor writing skills, your answer is more professional and accurate. I will replace this part with your description in the V6. _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
