Re: [PATCH 1/3] powerpc/mce: remove nmi_enter/exit from real mode handler

[Ganesh <ganeshgr@linux.ibm.com>]

On 9/17/20 5:50 PM, Michal Suchánek wrote:

> Hello,
>
> On Wed, Sep 16, 2020 at 10:52:26PM +0530, Ganesh Goudar wrote:
>> Use of nmi_enter/exit in real mode handler causes the kernel to panic
>> and reboot on injecting slb mutihit on pseries machine running in hash
>> mmu mode, As these calls try to accesses memory outside RMO region in
>> real mode handler where translation is disabled.
>>
>> Add check to not to use these calls on pseries machine running in hash
>> mmu mode.
>>
>> Fixes: 116ac378bb3f ("powerpc/64s: machine check interrupt update NMI accounting")
>> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
>> ---
>>   arch/powerpc/kernel/mce.c | 7 ++++++-
>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>> index ada59f6c4298..1d42fe0f5f9c 100644
>> --- a/arch/powerpc/kernel/mce.c
>> +++ b/arch/powerpc/kernel/mce.c
>> @@ -591,10 +591,15 @@ EXPORT_SYMBOL_GPL(machine_check_print_event_info);
>>   long notrace machine_check_early(struct pt_regs *regs)
>>   {
>>   	long handled = 0;
>> -	bool nested = in_nmi();
>> +	bool nested;
>> +	bool is_pseries_hpt_guest;
>>   	u8 ftrace_enabled = this_cpu_get_ftrace_enabled();
>>   
>>   	this_cpu_set_ftrace_enabled(0);
>> +	is_pseries_hpt_guest = machine_is(pseries) &&
>> +			       mmu_has_feature(MMU_FTR_HPTE_TABLE);
>> +	/* Do not use nmi_enter/exit for pseries hpte guest */
>> +	nested = is_pseries_hpt_guest ? true : in_nmi();
> As pointed out already in another comment nesting is supported natively
> since 69ea03b56ed2c7189ccd0b5910ad39f3cad1df21. You can simply do
> nmi_enter and nmi_exit unconditionally - or only based on
> is_pseries_hpt_guest.
ok
> The other question is what is the value of calling nmi_enter here at
> all. It crashes in one case, we simply skip it for that case, and we are
> good. Maybe we could skip it altogether?
Not sure why nmi_enter/exit is needed here, Again, Nick may have a reason.
> Thanks
>
> Michal