lkml.org 
[lkml]   [2022]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] panic, kexec: Don't mutex_trylock() in __crash_kexec()
    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

    \
     
     \ /
      Last update: 2022-06-17 17:14    [W:5.635 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site