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:	Sat, 26 Jul 2014 12:56:19 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Alexei Starovoitov <ast@...nel.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 Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf
<markus@...ppelsdorf.de> wrote:
>
> But fortunately the workaround for the new inode.c bug is the same as
> for the original bug: -fno-var-tracking-assignments.
>
> It would make sense to enabled it unconditionally for all debug
> configurations for now.

So how is code generation affected - if at all? Does the whole
"var-tracking-assignments" thing *only* matter for debug information?

Also, when was it introduced as an option? Can we just unconditionally
enable it, or do we need to be careful about gcc versions?

I'd *like* a debug kernel to not differ significantly from a non-debug
kernel. Most sane kernel developers (where "sane" is "me" by
definition) do not tend to use debug kernels, because the debug
overhead is absolutely disgustingly enormous at build time. But if we
then have most users using distro kernels that had debug info enabled,
it would be sad if code generation differences are huge.

So I'd prefer to just unconditionally add that
"-fno-var-tracking-assignments" to the build.

I just tested it on one file (fs/dcache.c) and it made no difference
at all for my non-debug build. Is this expected?

Because if the only effect of "-fno-var-tracking-assignments" is
potentially slightly worse debug information for variables, I'll
enable it in a jiffy if it fixes this code generation bug. But I'd
like to get that confirmed.

Finally, for CONFIG_DEBUG_INFO_REDUCED, we already use
"-fno-var-tracking". Is that a stronger version that also disables
"var-tracking-assignments"?

Also, Michel - can you try  this patch if you still have your
gcc-4.9.0 install, and send me the resulting fair.s file again?

                        Linus

View attachment "patch.diff" of type "text/plain" (377 bytes)