linux-kernel - Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

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]

Date:   Thu, 21 Dec 2017 07:39:22 -0800
From:   Mike Travis <mike.travis@....com>
To:     Ingo Molnar <mingo@...nel.org>, Mike Travis <travis@....com>
CC:     Ingo Molnar <mingo@...hat.com>, Russ Anderson <rja@....com>,
        Dimitri Sivanich <sivanich@....com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>, Andrew Banman <abanman@....com>
Subject: Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors



On 12/21/2017 3:49 AM, Ingo Molnar wrote:
> 
> * Mike Travis <travis@....com> wrote:
> 
>>
>> This patchset handles the fixes made to the UV4 HUB for upcoming Intel
>> processors as there are some interface changes.
>>
>>      * Update uv_mmrs.h to prep for fixed defines for UV4A.
>>
>>      * Updates to handle UV4 vs. UV4A (fixed) arches.
>>
>>      * Updates to handle UV4 GAM (global addressable memory) MMRs fixes.
>>
>>      * Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.
>>
>>      * Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.
> 
> Sigh, has any of this been properly build tested? x86-64 allyesconfig produces a
> bunch of ugly warnings:

Admittedly, we don't have a setup to test too many upstream kernel 
builds with configs other than what our distros are shipping with.  We 
do test build specific earlier kernel releases that are current with the 
distro to insure (or at least understand) back port issues.

I will try this "allyesconfig" though I believe it introduces CONFIG 
items that cause problems where the resultant kernel doesn't boot on a 
UV system.  But if building is the only goal, then we can ignore them.

Are there any other standard configs that are required to build when 
CONFIG_X86_UV is defined?  (Since all of these changes are within the UV 
specific code.)

Thanks,
Mike
> 
> In file included from ./include/linux/kernel.h:14:0,
> arch/x86/kernel/apic/x2apic_uv_x.c: In function ‘map_mmioh_high_uv34’:
> ./include/linux/printk.h:308:2: warning: ‘id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:806:8: note: ‘id’ was declared here
> In file included from ./include/linux/kernel.h:14:0,
> ./include/linux/printk.h:308:2: warning: ‘m_io’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:804:19: note: ‘m_io’ was declared here
> In file included from ./include/linux/kernel.h:14:0,
> ./include/linux/printk.h:308:2: warning: ‘shift’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:804:12: note: ‘shift’ was declared here
> arch/x86/kernel/apic/x2apic_uv_x.c:856:14: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:846:9: warning: ‘nasid_mask’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> In file included from ./include/linux/kernel.h:14:0,
> ./include/linux/printk.h:308:2: warning: ‘base’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:801:16: note: ‘base’ was declared here
> arch/x86/kernel/apic/x2apic_uv_x.c:843:17: warning: ‘mmr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> arch/x86/kernel/apic/x2apic_uv_x.c:832:16: warning: ‘overlay’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> Thanks,
> 
> 	Ingo
>