Re: [PATCH 2/4] x86/platform/UV: Fix problem with bad UV4 EFI System Table causing panic

[Mike Travis <travis@sgi.com>]

On 7/29/2016 4:17 AM, Thomas Gleixner wrote:
> On Wed, 27 Jul 2016, Mike Travis wrote:
> 
>> Fix a problem that occurs if for some reason the UV4 EFI System Table
>> is not available, the check inadvertently can cause a panic.
>>
>> Reviewed-by: Dimitri Sivanich <sivanich@sgi.com>
>> Reviewed-by: Nathan Zimmer <nzimmer@sgi.com>
>> Tested-by: Frank Ramsay <framsay@sgi.com>
>> Tested-by: John Estabrook <estabrook@sgi.com>
>> Signed-off-by: Mike Travis <travis@sgi.com>
>> ---
>>  arch/x86/platform/uv/bios_uv.c |    7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> --- linux-3.12.orig/arch/x86/platform/uv/bios_uv.c
>> +++ linux-3.12/arch/x86/platform/uv/bios_uv.c
>> @@ -201,11 +201,12 @@ void uv_bios_init(void)
>>  	}
>>  
>>  	if (uv_systab->revision >= UV_SYSTAB_VERSION_UV4) {
>> +		int size = uv_systab->size;
>> +
>>  		iounmap(uv_systab);
>> -		uv_systab = ioremap(efi.uv_systab, uv_systab->size);
> 
> I think the changelog is bogus. What's happening here is a classic use after
> unmap, which you avoid by this change.
> 
>> +		uv_systab = ioremap(efi.uv_systab, size);
> 
> Hmm?
> 
> 	tglx
> 

You might be right, I'm not very familiar with the EFI transitions
between physical and virtual addresses.  I do know that it worked
until the later kernels and the EFI changes that have occurred.
Another engineer here (athorlton) is working that problem and he
is the one that discovered this snafu.

But yes, the original code was incorrect in any case.

Thanks,
Mike