Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1691657 > unrolled thread

[PATCH 0/8] x86: randconfig warning fixes

Started byArnd Bergmann <arnd@arndb.de>
First post2017-07-19 15:00 +0200
Last post2017-07-20 12:30 +0200
Articles 14 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/8] x86: randconfig warning fixes Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
    [PATCH 3/8] x86: math-emu: avoid bogus -Wint-in-bool-context warning Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
      [tip:x86/urgent] x86/fpu/math-emu: Avoid bogus  -Wint-in-bool-context warning tip-bot for Arnd Bergmann <tipbot@zytor.com> - 2017-07-20 12:30 +0200
    [PATCH 5/8] x86: silence build with "make -s" Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
      [tip:x86/urgent] x86/build: Silence the build with "make -s" tip-bot for Arnd Bergmann <tipbot@zytor.com> - 2017-07-20 12:40 +0200
    [PATCH 6/8] x86: add MULTIUSER dependency for KVM Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
      Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM Radim Krčmář <rkrcmar@redhat.com> - 2017-07-19 16:20 +0200
        Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM Arnd Bergmann <arnd@arndb.de> - 2017-07-19 16:20 +0200
          Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM Radim Krčmář <rkrcmar@redhat.com> - 2017-07-19 18:20 +0200
            Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM Paolo Bonzini <pbonzini@redhat.com> - 2017-07-23 15:50 +0200
    [PATCH 2/8] x86: math-emu: possible uninitialized variable use Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
      [tip:x86/urgent] x86/fpu/math-emu: Fix possible uninitialized  variable use tip-bot for Arnd Bergmann <tipbot@zytor.com> - 2017-07-20 12:30 +0200
    [PATCH 1/8] perf/x86: shut up false-positive -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2017-07-19 15:00 +0200
      [tip:x86/urgent] perf/x86: Shut up false-positive  -Wmaybe-uninitialized warning tip-bot for Arnd Bergmann <tipbot@zytor.com> - 2017-07-20 12:30 +0200

#1691657 — [PATCH 0/8] x86: randconfig warning fixes

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 0/8] x86: randconfig warning fixes
Message-ID<u4WK5-fH-17@gated-at.bofh.it>
Hi,

I've gone through old patches of mine that I carried in my randconfig
tree, to see which warnings are still present. Here is a set of
fixes for arch/x86. Most of them were sent before at some point
and missed out for one reason or another.

Please have another look and apply what you like.

	Arnd

Arnd Bergmann (8):
  perf/x86: shut up false-positive -Wmaybe-uninitialized warning
  x86: math-emu: possible uninitialized variable use
  x86: math-emu: avoid bogus -Wint-in-bool-context warning
  x86: io: add "memory" clobber to insb/insw/insl/outsb/outsw/outsl
  x86: silence build with "make -s"
  x86: add MULTIUSER dependency for KVM
  x86: add PCI dependency for PUNIT_ATOM_DEBUG
  x86: intel-mid: fix a format string overflow warning

 arch/x86/Kconfig.debug                                   |  1 +
 arch/x86/boot/Makefile                                   |  5 +++--
 arch/x86/events/core.c                                   |  4 ++--
 arch/x86/include/asm/io.h                                |  4 ++--
 arch/x86/kvm/Kconfig                                     |  2 +-
 arch/x86/math-emu/Makefile                               |  4 ++--
 arch/x86/math-emu/fpu_emu.h                              |  2 +-
 arch/x86/math-emu/reg_compare.c                          | 16 ++++++++--------
 .../platform/intel-mid/device_libs/platform_max7315.c    |  6 ++++--
 9 files changed, 24 insertions(+), 20 deletions(-)

-- 
2.9.0

[toc] | [next] | [standalone]

#1691659 — [PATCH 3/8] x86: math-emu: avoid bogus -Wint-in-bool-context warning

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 3/8] x86: math-emu: avoid bogus -Wint-in-bool-context warning
Message-ID<u4WK6-fH-33@gated-at.bofh.it>
In reply to#1691657
gcc-7.1.1 produces this warning:

arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context]

This appears to be a bug in gcc-7.1.1, and I have reported it as
PR81484. The compiler suggests that code written as

	if (a & b ? c : d)

is usually incorrect and should have been

	if (a & (b ? c : d))

However, in this case, we correctly write

	if ((a & b) ? c : d)

and should not get a warning for it.

This adds a dirty workaround for the problem, adding a comparison with
zero inside of the macro. The warning is currently disabled in the kernel,
so we may decide not to apply the patch, and instead wait for future gcc
releases to fix the problem. On the other hand, it seems to be the
only instance of this particular problem.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Originally sent on July 14, this is the same patch again with
an rewritten changelog.
---
 arch/x86/math-emu/fpu_emu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/math-emu/fpu_emu.h b/arch/x86/math-emu/fpu_emu.h
index afbc4d805d66..c9c320dccca1 100644
--- a/arch/x86/math-emu/fpu_emu.h
+++ b/arch/x86/math-emu/fpu_emu.h
@@ -157,7 +157,7 @@ extern u_char const data_sizes_16[32];
 
 #define signbyte(a) (((u_char *)(a))[9])
 #define getsign(a) (signbyte(a) & 0x80)
-#define setsign(a,b) { if (b) signbyte(a) |= 0x80; else signbyte(a) &= 0x7f; }
+#define setsign(a,b) { if ((b) != 0) signbyte(a) |= 0x80; else signbyte(a) &= 0x7f; }
 #define copysign(a,b) { if (getsign(a)) signbyte(b) |= 0x80; \
                         else signbyte(b) &= 0x7f; }
 #define changesign(a) { signbyte(a) ^= 0x80; }
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1692752 — [tip:x86/urgent] x86/fpu/math-emu: Avoid bogus -Wint-in-bool-context warning

Fromtip-bot for Arnd Bergmann <tipbot@zytor.com>
Date2017-07-20 12:30 +0200
Subject[tip:x86/urgent] x86/fpu/math-emu: Avoid bogus -Wint-in-bool-context warning
Message-ID<u5gSu-5Zw-25@gated-at.bofh.it>
In reply to#1691659
Commit-ID:  5623452a0eaec1d44cc9f0770444a48847c9953f
Gitweb:     http://git.kernel.org/tip/5623452a0eaec1d44cc9f0770444a48847c9953f
Author:     Arnd Bergmann <arnd@arndb.de>
AuthorDate: Wed, 19 Jul 2017 14:53:01 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 20 Jul 2017 10:46:24 +0200

x86/fpu/math-emu: Avoid bogus -Wint-in-bool-context warning

gcc-7.1.1 produces this warning:

  arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
  arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context]

This appears to be a bug in gcc-7.1.1, and I have reported it as
PR81484. The compiler suggests that code written as

	if (a & b ? c : d)

is usually incorrect and should have been

	if (a & (b ? c : d))

However, in this case, we correctly write

	if ((a & b) ? c : d)

and should not get a warning for it.

This adds a dirty workaround for the problem, adding a comparison with
zero inside of the macro. The warning is currently disabled in the kernel,
so we may decide not to apply the patch, and instead wait for future gcc
releases to fix the problem. On the other hand, it seems to be the
only instance of this particular problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bill Metzenthen <billm@melbpc.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-4-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/math-emu/fpu_emu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/math-emu/fpu_emu.h b/arch/x86/math-emu/fpu_emu.h
index afbc4d8..c9c320d 100644
--- a/arch/x86/math-emu/fpu_emu.h
+++ b/arch/x86/math-emu/fpu_emu.h
@@ -157,7 +157,7 @@ extern u_char const data_sizes_16[32];
 
 #define signbyte(a) (((u_char *)(a))[9])
 #define getsign(a) (signbyte(a) & 0x80)
-#define setsign(a,b) { if (b) signbyte(a) |= 0x80; else signbyte(a) &= 0x7f; }
+#define setsign(a,b) { if ((b) != 0) signbyte(a) |= 0x80; else signbyte(a) &= 0x7f; }
 #define copysign(a,b) { if (getsign(a)) signbyte(b) |= 0x80; \
                         else signbyte(b) &= 0x7f; }
 #define changesign(a) { signbyte(a) ^= 0x80; }

[toc] | [prev] | [next] | [standalone]

#1691660 — [PATCH 5/8] x86: silence build with "make -s"

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 5/8] x86: silence build with "make -s"
Message-ID<u4WK6-fH-31@gated-at.bofh.it>
In reply to#1691657
Every kernel build on x86 will result in some output:

Setup is 13084 bytes (padded to 13312 bytes).
System is 4833 kB
CRC 6d35fa35
Kernel: arch/x86/boot/bzImage is ready  (#2)

This shuts it up, so that 'make -s' is truely silent as long as
everything works. Building without '-s' should produce unchanged
output.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/boot/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 0d810fb15eac..d88a2fddba8c 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -73,12 +73,13 @@ UBSAN_SANITIZE := n
 $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
 quiet_cmd_image = BUILD   $@
+silent_redirect_image = >/dev/null
 cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
-			       $(obj)/zoffset.h $@
+			       $(obj)/zoffset.h $@ $($(quiet)redirect_image)
 
 $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
 	$(call if_changed,image)
-	@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
+	@$(kecho) 'Kernel: $@ is ready' ' (#'`cat .version`')'
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
 $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1692774 — [tip:x86/urgent] x86/build: Silence the build with "make -s"

Fromtip-bot for Arnd Bergmann <tipbot@zytor.com>
Date2017-07-20 12:40 +0200
Subject[tip:x86/urgent] x86/build: Silence the build with "make -s"
Message-ID<u5h2a-63o-27@gated-at.bofh.it>
In reply to#1691660
Commit-ID:  d460131dd50599e0e9405d5f4ae02c27d529a44a
Gitweb:     http://git.kernel.org/tip/d460131dd50599e0e9405d5f4ae02c27d529a44a
Author:     Arnd Bergmann <arnd@arndb.de>
AuthorDate: Wed, 19 Jul 2017 14:53:03 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 20 Jul 2017 10:46:24 +0200

x86/build: Silence the build with "make -s"

Every kernel build on x86 will result in some output:

  Setup is 13084 bytes (padded to 13312 bytes).
  System is 4833 kB
  CRC 6d35fa35
  Kernel: arch/x86/boot/bzImage is ready  (#2)

This shuts it up, so that 'make -s' is truely silent as long as
everything works. Building without '-s' should produce unchanged
output.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-6-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/boot/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 0d810fb..d88a2fd 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -73,12 +73,13 @@ UBSAN_SANITIZE := n
 $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
 quiet_cmd_image = BUILD   $@
+silent_redirect_image = >/dev/null
 cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
-			       $(obj)/zoffset.h $@
+			       $(obj)/zoffset.h $@ $($(quiet)redirect_image)
 
 $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
 	$(call if_changed,image)
-	@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
+	@$(kecho) 'Kernel: $@ is ready' ' (#'`cat .version`')'
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
 $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE

[toc] | [prev] | [next] | [standalone]

#1691662 — [PATCH 6/8] x86: add MULTIUSER dependency for KVM

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 6/8] x86: add MULTIUSER dependency for KVM
Message-ID<u4WK7-fH-41@gated-at.bofh.it>
In reply to#1691657
KVM tries to select 'TASKSTATS', which had additional dependencies:

warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/kvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 760433b2574a..2688c7dc5323 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -22,7 +22,7 @@ config KVM
 	depends on HAVE_KVM
 	depends on HIGH_RES_TIMERS
 	# for TASKSTATS/TASK_DELAY_ACCT:
-	depends on NET
+	depends on NET && MULTIUSER
 	select PREEMPT_NOTIFIERS
 	select MMU_NOTIFIER
 	select ANON_INODES
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1691707 — Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

FromRadim Krčmář <rkrcmar@redhat.com>
Date2017-07-19 16:20 +0200
SubjectRe: [PATCH 6/8] x86: add MULTIUSER dependency for KVM
Message-ID<u4XZv-1ff-1@gated-at.bofh.it>
In reply to#1691662
2017-07-19 14:53+0200, Arnd Bergmann:
> KVM tries to select 'TASKSTATS', which had additional dependencies:
> 
> warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Hm, do you know why Kconfig warns instead of propagating the
dependencies?

> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> @@ -22,7 +22,7 @@ config KVM
>  	# for TASKSTATS/TASK_DELAY_ACCT:
> -	depends on NET
> +	depends on NET && MULTIUSER

The current condition goes halfway to nowhere, so the patch is
definitely an improvement, even if the result is not good ...

Applied, thanks.

[toc] | [prev] | [next] | [standalone]

#1691708 — Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 16:20 +0200
SubjectRe: [PATCH 6/8] x86: add MULTIUSER dependency for KVM
Message-ID<u4XZv-1ff-3@gated-at.bofh.it>
In reply to#1691707
On Wed, Jul 19, 2017 at 4:11 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> 2017-07-19 14:53+0200, Arnd Bergmann:
>> KVM tries to select 'TASKSTATS', which had additional dependencies:
>>
>> warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>
> Hm, do you know why Kconfig warns instead of propagating the
> dependencies?

Kconfig propagates 'depends on' dependencies, but cannot turn a 'select'
into 'depends on', as those two mean different things.

Another solution to the problem would be to use 'depends on TASKSTATS'.

Generally speaking, using 'select' to turn on a user-visible option is a bad
idea, but blindly turning those 'select' into 'depends on' is also dangerous,
as it can break configurations of existing users that would here end up with
neither TASKSTATS nor KVM after a 'make oldconfig'.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1692003 — Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

FromRadim Krčmář <rkrcmar@redhat.com>
Date2017-07-19 18:20 +0200
SubjectRe: [PATCH 6/8] x86: add MULTIUSER dependency for KVM
Message-ID<u4ZRE-2BD-29@gated-at.bofh.it>
In reply to#1691708
2017-07-19 16:18+0200, Arnd Bergmann:
> On Wed, Jul 19, 2017 at 4:11 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> > 2017-07-19 14:53+0200, Arnd Bergmann:
> >> KVM tries to select 'TASKSTATS', which had additional dependencies:
> >>
> >> warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> ---
> >
> > Hm, do you know why Kconfig warns instead of propagating the
> > dependencies?
> 
> Kconfig propagates 'depends on' dependencies, but cannot turn a 'select'
> into 'depends on', as those two mean different things.
> 
> Another solution to the problem would be to use 'depends on TASKSTATS'.

Good point, 'select' seems misused here.

There is no reason to depend on TASKSTATS (nor NET+MULTIUSER), we only
suggest to enable it with KVM.  KVM uses sched_info_on() to handle any
any possible resulting configuration, c9aaa8957f20 ("KVM: Steal time
implementation").

KVM would work as intended if 'select' would not enable the option if
its dependencies failed (instead of unconditionally forcing the option).

Is the preferred way to encode it:

  'default y if KVM' in config TASK_DELAY_ACCT
  (that adds a non-local and enigmatic dependency and also needlessly
   expands the possible configuration space)

or

  'select TASKSTATS if NET && MULTIUSER' in config KVM
  (that is going to break when dependencies of TASKSTATS change again)

?

thanks.

[toc] | [prev] | [next] | [standalone]

#1694311 — Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

FromPaolo Bonzini <pbonzini@redhat.com>
Date2017-07-23 15:50 +0200
SubjectRe: [PATCH 6/8] x86: add MULTIUSER dependency for KVM
Message-ID<u6pqF-8ae-5@gated-at.bofh.it>
In reply to#1692003
On 19/07/2017 18:13, Radim Krčmář wrote:
> Good point, 'select' seems misused here.
> 
> There is no reason to depend on TASKSTATS (nor NET+MULTIUSER), we only
> suggest to enable it with KVM.  KVM uses sched_info_on() to handle any
> any possible resulting configuration, c9aaa8957f20 ("KVM: Steal time
> implementation").
> 
> KVM would work as intended if 'select' would not enable the option if
> its dependencies failed (instead of unconditionally forcing the option).
> 
> Is the preferred way to encode it:
> 
>   'default y if KVM' in config TASK_DELAY_ACCT
>   (that adds a non-local and enigmatic dependency and also needlessly
>    expands the possible configuration space)
> 
> or
> 
>   'select TASKSTATS if NET && MULTIUSER' in config KVM
>   (that is going to break when dependencies of TASKSTATS change again)
> 
> ?

I think the former is the closest to what the user actually wants, and
it would let us clean up arch/x86/kvm/Kconfig.  However it should be
"default y if KVM && X86'.

Maybe there is room for a new operator "suggest Y" which, when added
inside "config X", operates as if "config Y" had a "default y if X".

In this case, kvm could do

-	depends on NET && MULTIUSER
-	select TASKSTATS
+	suggest TASKSTATS

Thanks,

Paolo

[toc] | [prev] | [next] | [standalone]

#1691663 — [PATCH 2/8] x86: math-emu: possible uninitialized variable use

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 2/8] x86: math-emu: possible uninitialized variable use
Message-ID<u4WK7-fH-47@gated-at.bofh.it>
In reply to#1691657
When building the kernel with "make EXTRA_CFLAGS=...", this overrides
the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile,
and we run into a build warning:

arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’:
arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This fixes the implementation to work correctly even without the PARANOID
flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable
but instead use the ccflags-y variable in the Makefile that is meant
for this purpose.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Originally sent on Oct. 17 2016, resending unmodified
---
 arch/x86/math-emu/Makefile      |  4 ++--
 arch/x86/math-emu/reg_compare.c | 16 ++++++++--------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/math-emu/Makefile b/arch/x86/math-emu/Makefile
index 9b0c63b60302..1b2dac174321 100644
--- a/arch/x86/math-emu/Makefile
+++ b/arch/x86/math-emu/Makefile
@@ -5,8 +5,8 @@
 #DEBUG	= -DDEBUGGING
 DEBUG	=
 PARANOID = -DPARANOID
-EXTRA_CFLAGS	:= $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
-EXTRA_AFLAGS	:= $(PARANOID)
+ccflags-y += $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
+asflags-y += $(PARANOID)
 
 # From 'C' language sources:
 C_OBJS =fpu_entry.o errors.o \
diff --git a/arch/x86/math-emu/reg_compare.c b/arch/x86/math-emu/reg_compare.c
index b77360fdbf4a..19b33b50adfa 100644
--- a/arch/x86/math-emu/reg_compare.c
+++ b/arch/x86/math-emu/reg_compare.c
@@ -168,7 +168,7 @@ static int compare(FPU_REG const *b, int tagb)
 /* This function requires that st(0) is not empty */
 int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 {
-	int f = 0, c;
+	int f, c;
 
 	c = compare(loaded_data, loaded_tag);
 
@@ -189,12 +189,12 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x121);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -205,7 +205,7 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 
 static int compare_st_st(int nr)
 {
-	int f = 0, c;
+	int f, c;
 	FPU_REG *st_ptr;
 
 	if (!NOT_EMPTY(0) || !NOT_EMPTY(nr)) {
@@ -235,12 +235,12 @@ static int compare_st_st(int nr)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -283,12 +283,12 @@ static int compare_i_st_st(int nr)
 	case COMP_No_Comp:
 		f = X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF;
 		break;
-#ifdef PARANOID
 	default:
+#ifdef PARANOID
 		EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 		f = 0;
 		break;
-#endif /* PARANOID */
 	}
 	FPU_EFLAGS = (FPU_EFLAGS & ~(X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF)) | f;
 	if (c & COMP_Denormal) {
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1692745 — [tip:x86/urgent] x86/fpu/math-emu: Fix possible uninitialized variable use

Fromtip-bot for Arnd Bergmann <tipbot@zytor.com>
Date2017-07-20 12:30 +0200
Subject[tip:x86/urgent] x86/fpu/math-emu: Fix possible uninitialized variable use
Message-ID<u5gSt-5Zw-11@gated-at.bofh.it>
In reply to#1691663
Commit-ID:  75e2f0a6b16141cb347f442033ec907380d4d66e
Gitweb:     http://git.kernel.org/tip/75e2f0a6b16141cb347f442033ec907380d4d66e
Author:     Arnd Bergmann <arnd@arndb.de>
AuthorDate: Wed, 19 Jul 2017 14:53:00 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 20 Jul 2017 10:46:24 +0200

x86/fpu/math-emu: Fix possible uninitialized variable use

When building the kernel with "make EXTRA_CFLAGS=...", this overrides
the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile,
and we run into a build warning:

  arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’:
  arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This fixes the implementation to work correctly even without the PARANOID
flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable
but instead use the ccflags-y variable in the Makefile that is meant
for this purpose.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bill Metzenthen <billm@melbpc.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-3-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/math-emu/Makefile      |  4 ++--
 arch/x86/math-emu/reg_compare.c | 16 ++++++++--------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/math-emu/Makefile b/arch/x86/math-emu/Makefile
index 9b0c63b..1b2dac1 100644
--- a/arch/x86/math-emu/Makefile
+++ b/arch/x86/math-emu/Makefile
@@ -5,8 +5,8 @@
 #DEBUG	= -DDEBUGGING
 DEBUG	=
 PARANOID = -DPARANOID
-EXTRA_CFLAGS	:= $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
-EXTRA_AFLAGS	:= $(PARANOID)
+ccflags-y += $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
+asflags-y += $(PARANOID)
 
 # From 'C' language sources:
 C_OBJS =fpu_entry.o errors.o \
diff --git a/arch/x86/math-emu/reg_compare.c b/arch/x86/math-emu/reg_compare.c
index b77360f..19b33b5 100644
--- a/arch/x86/math-emu/reg_compare.c
+++ b/arch/x86/math-emu/reg_compare.c
@@ -168,7 +168,7 @@ static int compare(FPU_REG const *b, int tagb)
 /* This function requires that st(0) is not empty */
 int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 {
-	int f = 0, c;
+	int f, c;
 
 	c = compare(loaded_data, loaded_tag);
 
@@ -189,12 +189,12 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x121);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -205,7 +205,7 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 
 static int compare_st_st(int nr)
 {
-	int f = 0, c;
+	int f, c;
 	FPU_REG *st_ptr;
 
 	if (!NOT_EMPTY(0) || !NOT_EMPTY(nr)) {
@@ -235,12 +235,12 @@ static int compare_st_st(int nr)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -283,12 +283,12 @@ static int compare_i_st_st(int nr)
 	case COMP_No_Comp:
 		f = X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF;
 		break;
-#ifdef PARANOID
 	default:
+#ifdef PARANOID
 		EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 		f = 0;
 		break;
-#endif /* PARANOID */
 	}
 	FPU_EFLAGS = (FPU_EFLAGS & ~(X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF)) | f;
 	if (c & COMP_Denormal) {

[toc] | [prev] | [next] | [standalone]

#1691670 — [PATCH 1/8] perf/x86: shut up false-positive -Wmaybe-uninitialized warning

FromArnd Bergmann <arnd@arndb.de>
Date2017-07-19 15:00 +0200
Subject[PATCH 1/8] perf/x86: shut up false-positive -Wmaybe-uninitialized warning
Message-ID<u4WK7-fH-59@gated-at.bofh.it>
In reply to#1691657
The intialization function checks for various failure scenarios, but
unfortunately the compiler gets a little confused about the possible
combinations, leading to a false-positive build warning when
-Wmaybe-uninitialized is set:

arch/x86/events/core.c: In function ‘init_hw_perf_events’:
arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n",

We can't actually run into this case, so this shuts up the warning
by initializing the variables to a known-invalid state.

Link: https://patchwork.kernel.org/patch/9392595/
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: replaced original patch that reordered the code instead of
adding a fake initialization.
---
 arch/x86/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index ff1ea2fb9705..8e3db8f642a7 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -191,8 +191,8 @@ static void release_pmc_hardware(void) {}
 
 static bool check_hw_exists(void)
 {
-	u64 val, val_fail, val_new= ~0;
-	int i, reg, reg_fail, ret = 0;
+	u64 val, val_fail = -1, val_new= ~0;
+	int i, reg, reg_fail = -1, ret = 0;
 	int bios_fail = 0;
 	int reg_safe = -1;
 
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1692741 — [tip:x86/urgent] perf/x86: Shut up false-positive -Wmaybe-uninitialized warning

Fromtip-bot for Arnd Bergmann <tipbot@zytor.com>
Date2017-07-20 12:30 +0200
Subject[tip:x86/urgent] perf/x86: Shut up false-positive -Wmaybe-uninitialized warning
Message-ID<u5gSt-5Zw-1@gated-at.bofh.it>
In reply to#1691670
Commit-ID:  11d8b05855f3749bcb6c57e2c4052921b9605c77
Gitweb:     http://git.kernel.org/tip/11d8b05855f3749bcb6c57e2c4052921b9605c77
Author:     Arnd Bergmann <arnd@arndb.de>
AuthorDate: Wed, 19 Jul 2017 14:52:59 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 20 Jul 2017 10:46:23 +0200

perf/x86: Shut up false-positive -Wmaybe-uninitialized warning

The intialization function checks for various failure scenarios, but
unfortunately the compiler gets a little confused about the possible
combinations, leading to a false-positive build warning when
-Wmaybe-uninitialized is set:

  arch/x86/events/core.c: In function ‘init_hw_perf_events’:
  arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n",

We can't actually run into this case, so this shuts up the warning
by initializing the variables to a known-invalid state.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170719125310.2487451-2-arnd@arndb.de
Link: https://patchwork.kernel.org/patch/9392595/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index ff1ea2f..8e3db8f 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -191,8 +191,8 @@ static void release_pmc_hardware(void) {}
 
 static bool check_hw_exists(void)
 {
-	u64 val, val_fail, val_new= ~0;
-	int i, reg, reg_fail, ret = 0;
+	u64 val, val_fail = -1, val_new= ~0;
+	int i, reg, reg_fail = -1, ret = 0;
 	int bios_fail = 0;
 	int reg_safe = -1;

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web