Message-ID: <81f5d521-bc8a-4d1a-fe7e-55487f3d25b3@huawei.com>
Date:   Thu, 23 Feb 2023 10:29:33 +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
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>
From:   Zeng Heng <zengheng4@huawei.com>
In-Reply-To: <87r0uh5yud.fsf@email.froward.int.ebiederm.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 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

How to just leave NMIs disabled, could you explain it with more details ?

Zeng Heng

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