linux-kernel - Re: [announce] new tree: "fix all build warnings, on all configs"

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:	Fri, 17 Oct 2008 21:12:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Howells <dhowells@...hat.com>
Subject: Re: [announce] new tree: "fix all build warnings, on all configs"


* Roland Dreier <rdreier@...co.com> wrote:

> However I worry about warnings produced by gcc bugs forcing us to 
> tinker with correct code.  Maybe it just makes sense to wait and see 
> if we ever hit a case where a gcc bug forces us to make too many 
> stupid changes, and figure out what to do if and when that happens.

i certainly have a found a couple of such cases, see tip/warnings/ugly - 
for example see the one below where gcc is not able to see through type 
width.

the threshold i'm using is: "does the code get worse". Another question 
is the rate of really ugly patches. Had i ended up with a lot of them 
i'd be worried - but right now they are in the low single digits, for a 
full 9 MLOC kernel - which seems manageable.

the drivers/net/mlx4/mcg.c commit you pointed out is one of the very few 
borderline cases: the code gets neither better, nor worse. If you look 
at the totality of fixes they are not common at all. (and almost by 
definition the 100-200 unfixed warnings that we have piled up in -git 
are the _problematic_ cases - clear-cut cases tend to be fixed.)

	Ingo

------------->
>From fbf03326a16b29f8d34a5a3883a267bac4d38fc2 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Wed, 27 Aug 2008 12:44:00 +0200
Subject: [PATCH] hack, workaround for warning drivers/acpi/tables/tbfadt.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

ugly workaround for this warning:

  drivers/acpi/tables/tbfadt.c: In function ‘acpi_tb_create_local_fadt’:
  include/asm/string_32.h:75: warning: array subscript is above array bounds

gcc 4.3.1 20080801 (Red Hat 4.3.1-6)

its array checks are borked. Switch the string_32.h code to short instead.

NOT-Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 include/asm-x86/string_32.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-x86/string_32.h b/include/asm-x86/string_32.h
index 487843e..419ab10 100644
--- a/include/asm-x86/string_32.h
+++ b/include/asm-x86/string_32.h
@@ -72,7 +72,7 @@ static __always_inline void *__constant_memcpy(void *to, const void *from,
 		return to;
 	case 5:
 		*(int *)to = *(int *)from;
-		*((char *)to + 4) = *((char *)from + 4);
+		*((short *)to + 3) = *((short *)from + 3);
 		return to;
 	case 6:
 		*(int *)to = *(int *)from;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/