linux-kernel - Re: Random panic in load

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:	Mon, 28 Jul 2014 20:41:53 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alexei Starovoitov <ast@...nel.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Michel Dänzer <michel@...nzer.net>,
	Jakub Jelinek <jakub@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Debian GCC Maintainers <debian-gcc@...ts.debian.org>,
	Debian Kernel Team <debian-kernel@...ts.debian.org>
Subject: Re: Random panic in load_balance() with 3.16-rc

On 2014.07.28 at 11:28 -0700, Linus Torvalds wrote:
> On Mon, Jul 28, 2014 at 11:09 AM, Markus Trippelsdorf
> <markus@...ppelsdorf.de> wrote:
> >
> > It shouldn't be too hard to implement a simple check for the bug in the
> > next release. Just compile the gcc/testsuite/gcc.target/i386/pr61801.c
> > testcase with -fcompare-debug. If gcc returns 0 then
> > -fvar-tracking-assignments could safely be enabled again.
> 
> We don't really have any good infrastructure for things like this,
> though. We probably *should* have a way to generate config options by
> compiler version, but right now we don't. We do random ugly things
> from within Makefile shell escapes (see all the helpers for this we do
> in scripts/Kbuild.include, for example), and we could add yet another
> one. But this is a whole new level of "ugly hack". It would be better
> if we could do things like this at config time, not at build-time with
> Makefile hacks.
> 
> Also, the test-case seems to be very sensitive to compiler options: it
> passes with "-O", but fails with "-O2" or "-Os" for me. So I wonder
> how reliable it is in the face of compiler version differences (ie is
> it really robust wrt the bug actually being *fixed*, or is it a bit of
> a happenstance)

It is robust with -O2 and -Os for all supported series that I've
checked: 4.8, 4.9 and 5.0. I haven't checked older releases.

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