linux-kernel - [PATCH] x86: oprofile: nmi_int: fix bogus gcc-8 warning

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-next>] [day] [month] [year] [list]

Date:   Tue, 20 Feb 2018 21:58:21 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Robert Richter <rric@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org
Cc:     Arnd Bergmann <arnd@...db.de>, Martin Sebor <msebor@....gnu.org>,
        stable@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>,
        Jessica Yu <jeyu@...nel.org>, oprofile-list@...ts.sf.net,
        linux-kernel@...r.kernel.org
Subject: [PATCH] x86: oprofile: nmi_int: fix bogus gcc-8 warning

gcc-8 shows a warning for the x86 oprofile code that copies per-cpu
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:

arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
  memcpy(per_cpu(cpu_msrs, cpu).multiplex,
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         per_cpu(cpu_msrs, 0).multiplex,
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         sizeof(struct op_msr) * model->num_virt_counters);
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]

I have analyzed a number of such warnings now: some are valid and the
gcc warning is welcome. Others turned out to be false-positives, and
gcc was changed to not warn about those any more. This is a corner case
that is a false-positive but the gcc developers feel it's better to keep
warning about it.

In this case, it seems best to work around it by telling gcc
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check. Cc:stable as we also want
old kernels to build cleanly with gcc-8.

Cc: Martin Sebor <msebor@....gnu.org>
Cc: stable@...r.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
 arch/x86/oprofile/nmi_int.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/oprofile/nmi_int.c b/arch/x86/oprofile/nmi_int.c
index 174c59774cc9..1d6d14db96c0 100644
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -460,7 +460,7 @@ static int nmi_setup(void)
 		goto fail;
 
 	for_each_possible_cpu(cpu) {
-		if (!cpu)
+		if (!IS_ENABLED(CONFIG_SMP) || !cpu)
 			continue;
 
 		memcpy(per_cpu(cpu_msrs, cpu).counters,
@@ -470,7 +470,6 @@ static int nmi_setup(void)
 		memcpy(per_cpu(cpu_msrs, cpu).controls,
 		       per_cpu(cpu_msrs, 0).controls,
 		       sizeof(struct op_msr) * model->num_controls);
-
 		mux_clone(cpu);
 	}
 
-- 
2.9.0