From: Liuye <liu.yeC@h3c.com>
To: Jiri Slaby <jirislaby@kernel.org>,
"daniel.thompson@linaro.org" <daniel.thompson@linaro.org>
Cc: "dianders@chromium.org" <dianders@chromium.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"jason.wessel@windriver.com" <jason.wessel@windriver.com>,
"kgdb-bugreport@lists.sourceforge.net"
<kgdb-bugreport@lists.sourceforge.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Subject: 答复: [PATCH V4] kdb: Fix the deadlock issue in KDB debugging.
Date: Fri, 22 Mar 2024 07:50:54 +0000 [thread overview]
Message-ID: <5649fa8bfbdb43ea914850794afc6cac@h3c.com> (raw)
In-Reply-To: <d3b77177-7c00-4459-9515-37afe741e9dd@kernel.org>
>On 21. 03. 24, 12:50, liu.yec@h3c.com wrote:
>> From: LiuYe <liu.yeC@h3c.com>
>>
>> Currently, if CONFIG_KDB_KEYBOARD is enabled, then kgdboc will attempt
>> to use schedule_work() to provoke a keyboard reset when transitioning
>> out of the debugger and back to normal operation.
>> This can cause deadlock because schedule_work() is not NMI-safe.
>>
>> The stack trace below shows an example of the problem. In this case
>> the master cpu is not running from NMI but it has parked the slave
>> CPUs using an NMI and the parked CPUs is holding spinlocks needed by
>> schedule_work().
>
>I am missing here an explanation (perhaps because I cannot find any docs for irq_work) why irq_work works in this case.
Just need to postpone schedule_work to the slave CPU exiting the NMI context, and there will be no deadlock problem.
irq_work will only respond to handle schedule_work after master cpu 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.
>And why you need to schedule another work in the irq_work and not do the job directly.
In the function kgdboc_restore_input_helper , use mutex_lock for protection. The mutex lock cannot be used in interrupt context.
Guess that the process needs to run in the context of the process. Therefore, call schedule_work in irq_work. Keep the original flow unchanged.
next prev parent reply other threads:[~2024-03-22 7:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 2:56 [PATCH] kdb: Fix the deadlock issue in KDB debugging LiuYe
2024-02-28 12:05 ` Daniel Thompson
2024-03-01 3:30 ` 答复: " Liuye
2024-03-01 10:59 ` Daniel Thompson
2024-03-12 8:37 ` 答复: " Liuye
2024-03-12 9:57 ` Daniel Thompson
2024-03-12 10:04 ` 答复: " Liuye
2024-03-12 10:24 ` Daniel Thompson
2024-03-13 1:22 ` 答复: " Liuye
2024-03-13 14:17 ` Daniel Thompson
2024-03-14 7:06 ` 答复: " Liuye
2024-03-14 13:09 ` Daniel Thompson
2024-03-15 9:59 ` 答复: " Liuye
2024-03-16 2:34 ` [PATCH v1] " liu.yec
2024-03-20 16:28 ` Daniel Thompson
2024-03-21 2:26 ` [PATCH V3] " liu.yec
2024-03-21 7:38 ` Greg KH
2024-03-21 7:57 ` 答复: " Liuye
2024-03-21 11:04 ` Daniel Thompson
2024-03-21 11:50 ` [PATCH V4] " liu.yec
2024-03-22 6:54 ` Jiri Slaby
2024-03-22 7:50 ` Liuye [this message]
2024-03-22 15:58 ` 答复: " Daniel Thompson
2024-03-23 1:41 ` [PATCH V5] " liu.yec
2024-03-25 16:54 ` Daniel Thompson
2024-03-26 0:47 ` 答复: " Liuye
2024-03-26 7:40 ` [PATCH V6] " liu.yec
2024-03-26 8:22 ` Greg KH
2024-03-26 8:54 ` [PATCH V7] " liu.yec
2024-04-02 12:58 ` Daniel Thompson
2024-04-03 6:11 ` [PATCH V8] " liu.yec
2024-04-03 13:58 ` Daniel Thompson
2024-04-03 22:22 ` Andy Shevchenko
2024-04-08 1:44 ` LiuYe
2024-04-08 10:29 ` Andy Shevchenko
2024-04-09 2:03 ` [PATCH V9] " liu.yec
2024-04-10 2:06 ` [PATCH V10] " liu.yec
2024-04-10 3:59 ` Andy Shevchenko
2024-04-10 5:30 ` Greg KH
2024-04-10 5:54 ` 答复: " Liuye
2024-04-10 5:59 ` Greg KH
2024-04-10 6:10 ` 答复: " Liuye
2024-04-10 6:15 ` Greg KH
2024-04-10 6:30 ` 答复: " Liuye
2024-04-10 7:18 ` [PATCH V11] " liu.yec
2024-04-10 8:24 ` 答复: 答复: 答复: [PATCH V10] " Greg KH
2024-04-10 8:38 ` 答复: " Liuye
2024-03-02 20:44 ` [PATCH] " Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5649fa8bfbdb43ea914850794afc6cac@h3c.com \
--to=liu.yec@h3c.com \
--cc=daniel.thompson@linaro.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jason.wessel@windriver.com \
--cc=jirislaby@kernel.org \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).