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]
Message-ID: <20061005083754.GA1060@elte.hu>
Date:	Thu, 5 Oct 2006 10:37:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: make-bogus-warnings-go-away tree [was: 2.6.18-mm3]


* Andrew Morton <akpm@...l.org> wrote:

> - Added Jeff's make-bogus-warnings-go-away tree to the -mm lineup, as
>   git-gccbug.patch

Jeff: very nice! (I did this myself on a much smaller scale for the -rt 
patch, because it's just so lethal if some serious warning gets lost in 
the myriads of 'possible use of uninitialized' messages.)

A small suggestion: to give GCC folks a chance to actually fix this, 
could we actively annotate these places instead of working them around?
I.e., instead of:

        long cursor = 0;
        int error = 0;
-       void *new_mc;
+       void *new_mc = NULL;
        int cpu;
        cpumask_t old;

couldnt we do:

	void *new_mc __GCC_WARN_BUG;

and then do something like this in gcc.h:

 #ifdef CONFIG_ELIMINATE_BOGUS_GCC_WARNINGS
 # define __GCC_WARN_BUG = 0
 #else
 # define __GCC_WARN_BUG
 #endif

this both gives an in-source incentive for GCC folks to get rid of these 
bogus warnings (or remain shamed for eternity), and gives us the ability 
to control the presence of these workarounds (and the eventual ability 
to eliminate them in the future).

this would also mean we could merge your tree upstream without worrying 
about hiding gcc bugs.

	Ingo
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ