linux-kernel - 答复: [PATCH V5] kdb: Fix the deadlock issue in KDB debugging.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <284dbaad75574bbaaab803b471e8ca6c@h3c.com>
Date: Tue, 26 Mar 2024 00:47:05 +0000
From: Liuye <liu.yeC@....com>
To: Daniel Thompson <daniel.thompson@...aro.org>
CC: "jirislaby@...nel.org" <jirislaby@...nel.org>,
        "dianders@...omium.org"
	<dianders@...omium.org>,
        "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>,
        "jason.wessel@...driver.com"
	<jason.wessel@...driver.com>,
        "kgdb-bugreport@...ts.sourceforge.net"
	<kgdb-bugreport@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-serial@...r.kernel.org"
	<linux-serial@...r.kernel.org>
Subject: 答复: [PATCH V5] kdb: Fix the deadlock issue in KDB debugging.

>> Just need to postpone schedule_work to the slave CPU exiting the NMI context.
>>
>> irq_work will only respond to handle schedule_work after 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.
>>
>> It is the call to input_register_handler() that forces us not to do the work from irq_work's hardirq callback.
>>
>> Therefore schedule another work in the irq_work and not do the job directly.
>
>This looks like it was copy and pasted from the e-mail thread without any editing to make it make any sense. It not even formatted correctly (where are the line breaks?).
>
>How about:
>
>We fix the problem by using irq_work to call schedule_work() instead of calling it directly. irq_work is an NMI-safe deferred work framework that performs the requested work from a hardirq context (usually an IPI but it can be timer interrupt on some architectures).
>
>Note that we still need to  a workqueue since we cannot resync the keyboard state from the hardirq context provided by irq_work.
>That must be done from task context for the calls into the input subystem. Hence we must defer the work twice. First to safely switch from the debug trap (NMI-like context) to hardirq and then, secondly, to get from hardirq to the system workqueue.

I apologize for my poor writing skills, your answer is more professional and accurate. I will replace this part with your description in the V6.