In traditional kexec, the new kernel will replace current one, so the
irq is simply disabled. But now jumping back from kexeced kernel is
supported, so the irq should be enabled again.
The code sequence of irq during kexec jump is as follow:
local_irq_disable(); /* in kernel_kexec() */
local_irq_disable(); /* in machine_kexec() */
local_irq_enable(); /* in kernel_kexec() */
The disable and enable is not match. Maybe another method is to use
local_irq_save(), local_irq_restore() pair in machine_kexec(), so the
disable and enable is matched.
And its the machine kernel's lockdep instance that goes complain?
whichever annotation gets used - and I think I can agree that raw_*
might be approriate there, this should be accompanied with a rather
elaborate changelog and preferably a comment in the code too. Without
such we'll be wondering in the years to come WTH happens here.
Sorry, I find there is no complain from lockdep. Un-paired irq
disable/enable has no problem with lockdep, just increase something such
as "redundant_hardirqs_off". Please ignore this thread.