Message-ID: <0e26e06a-37af-8905-5b87-d1f96a74ab67@huawei.com>
Date:   Thu, 23 Feb 2023 11:14:00 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.2
Subject: Re: [RFC PATCH v4] x86/kdump: terminate watchdog NMI interrupt to
 avoid kdump crashes
Content-Language: en-US
From:   Zeng Heng <zengheng4@huawei.com>
To:     "Eric W. Biederman" <ebiederm@xmission.com>,
        Peter Zijlstra <peterz@infradead.org>
CC:     <alexander.shishkin@linux.intel.com>, <tglx@linutronix.de>,
        <tiwai@suse.de>, <jolsa@kernel.org>, <vbabka@suse.cz>,
        <keescook@chromium.org>, <mingo@redhat.com>, <acme@kernel.org>,
        <namhyung@kernel.org>, <bp@alien8.de>, <bhe@redhat.com>,
        <eric.devolder@oracle.com>, <hpa@zytor.com>, <jroedel@suse.de>,
        <dave.hansen@linux.intel.com>, <linux-perf-users@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <liwei391@huawei.com>,
        <x86@kernel.org>, <xiexiuqi@huawei.com>, <liaochang1@huawei.com>
References: <20230217120604.435608-1-zengheng4@huawei.com>
 <Y/ZMEesgPnRR3LsG@hirez.programming.kicks-ass.net>
 <87r0uh5yud.fsf@email.froward.int.ebiederm.org>
 <81f5d521-bc8a-4d1a-fe7e-55487f3d25b3@huawei.com>
In-Reply-To: <81f5d521-bc8a-4d1a-fe7e-55487f3d25b3@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 2023/2/23 10:29, Zeng Heng 写道:
>
> 在 2023/2/23 2:39, Eric W. Biederman 写道:
>> Peter Zijlstra <peterz@infradead.org> writes:
>>
>>> On Fri, Feb 17, 2023 at 08:06:04PM +0800, Zeng Heng wrote:
>>>> If the cpu panics within the NMI interrupt context, there could be
>>>> unhandled NMI interrupts in the background which are blocked by 
>>>> processor
>>>> until next IRET instruction executes. Since that, it prevents nested
>>>> NMI handler execution.
>>>>
>>>> In case of IRET execution during kdump reboot and no proper NMIs 
>>>> handler
>>>> registered at that point (such as during EFI loader)
>> EFI loader?  kexec on panic is supposed to be kernel to kernel.
>> If someone is getting EFI involved that is a bug.
>
> In kdump path, kexec would start purgatory to verify the secondary 
> kernel by
>
> sha256. If verify passed, it would turn the control to EFI loader, and 
> call the second
>
> kernel to capture the environment as vmcore file.
>
> As the mail said, if panic appears within NMI context, we never exit 
> from that until
>
> EFI loader handles page fault exception and executes IRET instruction 
> when exit
>
> from PF. At this moment, processor would allow the blocked NMI 
> interrupt raise.
>
>
>>> This kills all of perf, including but not limited to the hardware
>>> watchdog. However, it does nothing to external NMI sources like the NMI
>>> button found on some HP machines.
>>>
>>> Still I suppose it is sufficient for the normal case.
>> I can't think of one why we don't just leave
>> NMIs deliberately disabled
>
Inative_machine_crash_shutdown() has called lapic_shutdown() to disable 
any kind of

irq, but EFI loader assumes there is no any residual NMIs in the background.


Here is the first version for this issue:

https://lore.kernel.org/all/20230110102745.2514694-1-zengheng4@huawei.com/

Zeng Heng

>
>> until the crash recover kernel figured out how to enable them safely.
>>
>