linux-kernel - Explicitly marking initializer overrides (was "Re: [PATCH] arm64/cache: silence -Woverride-init warnings")

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190809083251.GA48423@lakrids.cambridge.arm.com>
Date:   Fri, 9 Aug 2019 09:32:51 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Nathan Chancellor <natechancellor@...il.com>
Cc:     Qian Cai <cai@....pw>, will@...nel.org, catalin.marinas@....com,
        linux-arm-kernel@...ts.infradead.org,
        clang-built-linux@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Explicitly marking initializer overrides (was "Re: [PATCH]
 arm64/cache: silence -Woverride-init warnings")

On Thu, Aug 08, 2019 at 10:09:16AM -0700, Nathan Chancellor wrote:
> On Thu, Aug 08, 2019 at 11:38:08AM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> > > The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> > > VIVT I-caches") introduced some compiation warnings from GCC (and
> > > Clang) with -Winitializer-overrides),
> > > 
> > > arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VIPT]  = "VIPT",
> > >                         ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> > > 'icache_policy_str[2]')
> > > arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_PIPT]  = "PIPT",
> > >                         ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> > > 'icache_policy_str[3]')
> > > arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VPIPT]  = "VPIPT",
> > >                          ^~~~~~~
> > > arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> > > 'icache_policy_str[0]')
> > > 
> > > because it initializes icache_policy_str[0 ... 3] twice. Since
> > > arm64 developers are keen to keep the style of initializing a static
> > > array with a non-zero pattern first, just disable those warnings for
> > > both GCC and Clang of this file.
> > > 
> > > Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> > > Signed-off-by: Qian Cai <cai@....pw>
> > 
> > This is _not_ a fix, and should not require backporting to stable trees.
> > 
> > What about all the other instances that we have in mainline?
> > 
> > I really don't think that we need to go down this road; we're just going
> > to end up adding this to every file that happens to include a header
> > using this scheme...
> > 
> > Please just turn this off by default for clang.
> > 
> > If we want to enable this, we need a mechanism to permit overridable
> > assignments as we use range initializers for.
> > 
> > Thanks,
> > Mark.
> > 
> 
> For what it's worth, this is disabled by default for clang in the
> kernel:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.extrawarn?h=v5.3-rc3#n69
> 
> It only becomes visible with clang at W=1 because that section doesn't
> get applied. It becomes visible with GCC at W=1 because of -Wextra.

Thanks for clarifying that!

Do you know if there's any existing mechanism that we can use to silence
the warning on a per-assignment basis? Either to say that an assignment
can be overridden, or that the assignment is expected to override an
existing assignment?

If not, who would be able to look at adding a mechanism to clang for
this?

If we could have some attribute or intrinsic that we could wrap like:

struct foo f = {
	.bar __defaultval = <default>,
	.bar = <newval>,		// no warning
	.bar = <anotherval>,		// warning
};

... or:

struct foo f = {
	.bar = <default>,
	.bar __override = <newval>,	// no warning
	.bar = <anotherval>,		// warning
};

... or:
	
	.bar = OVERRIDE(<newval>),	// no warning

... or:
	OVERRIDE(.bar) = <newval>,	// no warning

... then I think it would be possible to make use of the warning
effectively, as we could distinguish intentional overrides from
unintentional ones, and annotating assignments in this way doesn't seem
onerous to me.

Thanks,
Mark.