>> 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.
