On 17/06/22 17:13, Sebastian Andrzej Siewior wrote: > 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. > Both are good points, thank you for lighting my lantern :) >> 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. > Those were pretty much my thoughts. I *think* panic() can be re-entrant on the same CPU if the first entry was from NMI, but that still requires being able to schedule a thread that panics which isn't a given after getting that panic NMI. So for now actually doing the kexec in NMI (or IRQ) context seems to be the less hazardous route. > Sebastian _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
