From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Michel Dänzer" <michel@daenzer.net>,
"Jakub Jelinek" <jakub@redhat.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Debian GCC Maintainers" <debian-gcc@lists.debian.org>,
"Debian Kernel Team" <debian-kernel@lists.debian.org>
Subject: Re: Random panic in load_balance() with 3.16-rc
Date: Sat, 26 Jul 2014 22:19:14 +0200 [thread overview]
Message-ID: <20140726201914.GB21842@x4> (raw)
In-Reply-To: <CA+55aFyo=HVZGEYNmz9GHqLatFHiJYTviKz_dXjqCv8b_gGxBA@mail.gmail.com>
On 2014.07.26 at 12:56 -0700, Linus Torvalds wrote:
> On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf
> <markus@trippelsdorf.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
next prev parent reply other threads:[~2014-07-26 20:19 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53C77BB8.6030804@daenzer.net>
2014-07-17 7:58 ` Random panic in load_balance() with 3.16-rc Peter Zijlstra
2014-07-18 9:29 ` Michel Dänzer
2014-07-22 6:13 ` Michel Dänzer
2014-07-23 3:53 ` Michel Dänzer
2014-07-23 4:21 ` Linus Torvalds
2014-07-23 6:49 ` Peter Zijlstra
2014-07-23 8:05 ` Michel Dänzer
2014-07-23 8:28 ` Peter Zijlstra
2014-07-23 9:25 ` Peter Zijlstra
2014-07-23 9:31 ` Michel Dänzer
2014-07-23 9:45 ` Dietmar Eggemann
2014-07-23 11:11 ` Peter Zijlstra
2014-07-23 11:30 ` Peter Zijlstra
2014-07-23 14:24 ` Peter Zijlstra
2014-07-23 14:38 ` Michel Dänzer
2014-07-23 15:51 ` Linus Torvalds
[not found] ` <20140723155526.GW3935@laptop>
2014-07-23 16:54 ` Linus Torvalds
2014-07-23 17:03 ` Peter Zijlstra
2014-07-23 17:12 ` Linus Torvalds
2014-07-23 17:26 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:35 ` Linus Torvalds
2014-07-23 18:41 ` Peter Zijlstra
2014-07-23 18:55 ` Linus Torvalds
2014-07-23 19:02 ` Peter Zijlstra
2014-07-23 19:20 ` Linus Torvalds
2014-07-24 1:43 ` Michel Dänzer
2014-07-24 18:47 ` Linus Torvalds
2014-07-24 18:59 ` Peter Zijlstra
2014-07-25 1:25 ` Michel Dänzer
2014-07-25 2:33 ` Linus Torvalds
2014-07-25 2:50 ` Nick Krause
2014-07-25 2:36 ` Nick Krause
2014-07-25 3:55 ` Alexei Starovoitov
2014-07-25 4:00 ` Nick Krause
2014-07-25 14:02 ` Steven Rostedt
2014-07-25 18:29 ` Linus Torvalds
2014-07-25 19:10 ` Steven Rostedt
2014-07-25 20:01 ` Linus Torvalds
2014-07-25 20:13 ` Steven Rostedt
2014-07-25 21:25 ` Jakub Jelinek
2014-07-26 18:28 ` Linus Torvalds
2014-07-26 18:39 ` Linus Torvalds
2014-07-26 19:35 ` Markus Trippelsdorf
2014-07-26 19:55 ` Theodore Ts'o
2014-07-26 20:20 ` Markus Trippelsdorf
2014-07-26 22:08 ` Jakub Jelinek
2014-07-26 19:56 ` Linus Torvalds
2014-07-26 20:03 ` Linus Torvalds
2014-07-26 20:19 ` Markus Trippelsdorf [this message]
2014-07-26 20:39 ` Linus Torvalds
2014-07-28 12:26 ` Frank Ch. Eigler
2014-07-28 13:10 ` Theodore Ts'o
2014-07-28 14:11 ` Frank Ch. Eigler
2014-07-28 16:45 ` Linus Torvalds
2014-07-28 17:27 ` Alexei Starovoitov
2014-07-28 18:09 ` Markus Trippelsdorf
2014-07-28 18:28 ` Linus Torvalds
2014-07-28 18:41 ` Markus Trippelsdorf
2014-07-29 8:58 ` Jakub Jelinek
2014-07-28 19:50 ` Theodore Ts'o
2014-07-28 3:47 ` Michel Dänzer
2014-07-28 16:48 ` Linus Torvalds
2014-07-29 2:29 ` Michel Dänzer
2014-08-05 3:19 ` Steven Rostedt
2014-07-26 18:02 ` Steven Chamberlain
2014-07-29 9:20 ` Michel Dänzer
2014-07-25 6:48 ` Jakub Jelinek
2014-07-25 8:15 ` Linus Torvalds
2014-07-25 9:03 ` Michel Dänzer
2014-07-25 9:21 ` Markus Trippelsdorf
2014-07-25 9:42 ` Markus Trippelsdorf
2014-07-23 18:07 ` Linus Torvalds
2014-07-23 18:31 ` Peter Zijlstra
2014-07-23 18:24 ` Peter Zijlstra
2014-07-23 17:04 ` Peter Zijlstra
2014-07-23 17:15 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:23 ` Peter Zijlstra
2014-07-23 10:52 ` Peter Zijlstra
2014-07-24 7:18 ` Michel Dänzer
2014-07-24 7:51 ` Peter Zijlstra
2014-07-24 9:55 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140726201914.GB21842@x4 \
--to=markus@trippelsdorf.de \
--cc=ast@kernel.org \
--cc=debian-gcc@lists.debian.org \
--cc=debian-kernel@lists.debian.org \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.