On 2022-06-16 13:37:09 [+0100], Valentin Schneider wrote: > Regarding the original explanation for the WARN & return: > > I don't get why 2) is a problem - if the lock is acquired by the trylock > then the critical section will be run without interruption since it > cannot sleep, the interrupted task may get boosted but that will not > have any actual impact AFAICT. boosting an unrelated task is considered wrong. I don't know how bad it gets in terms of lock chains since a task is set as owner which did not actually ask for the lock. > Regardless, even if this doesn't sleep, the ->wait_lock in the slowpath > isn't NMI safe so this needs changing. This includes the unlock path which may wake a waiter and deboost. > I've thought about trying to defer the kexec out of an NMI (or IRQ) > context, but that pretty much means deferring the panic() which I'm > not sure is such a great idea. If we could defer it out of NMI on RT then it would work non-RT, too. If the system is "stuck" and the NMI is the only to respond then I guess that it is not a great idea. Sebastian _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
