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 22:19:14 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 2014.07.26 at 12:56 -0700, Linus Torvalds wrote:
> 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?

Yes. It should only affect the quality of the debugging information.
If code generation is affected it is a compiler bug.

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

Git blame says it was introduced:  Wed Sep 2 02:42:21 2009.

> 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?

Yes. The option only affects -g builds.

> 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"?

Yes.

So, the option should only be enabled for debugging builds. Something
like the following should be sufficient:

diff --git a/Makefile b/Makefile
index 6b2774145d66..037b78d0f407 100644
--- a/Makefile
+++ b/Makefile
@@ -689,7 +689,7 @@ endif
 endif
 
 ifdef CONFIG_DEBUG_INFO
-KBUILD_CFLAGS	+= -g
+KBUILD_CFLAGS	+= -g -fno-var-tracking-assignments
 KBUILD_AFLAGS	+= -Wa,-gdwarf-2
 endif
 
-- 
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/