Re: Random panic in load_balance() with 3.16-rc

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Jul 28, 2014 at 08:26:59AM -0400, Frank Ch. Eigler wrote:
> Please note that the data produced by "-g -fvar-tracking" is consumed
> by tools like systemtap, perf, crash, and makes a significant
> difference to the observability of debug AND non-debug kernels.  (The
> presence of compiled-in DEBUG_* self-checking code is orthogonal to
> kernel observability via debuginfo.)  Please consider only disabling
> var-tracking optionally/temporarily to work around this already-fixed
> compiler bug, but not losing high-quality dwarf data permanently.

I thought Markus told us that -fno-var-tracking-assignments makes
absolutely no difference for non-debug kernels?

For cases where it's really critical that userspace know whether a
particular kernel bug or feature is present, one of the tricks I use
is the presence or absense of a file in /sys/fs/ext4/features.  That
way, userspace can reliably detect if feature or bug fix is present,
without relying solely on a version check which doesn't take into
account enterprise distro backports.

Is there some equivalent signalling system that gcc could use, so that
the Makefile can test whether or not -fvar-tracking is needed to avoid
creating an unstable kernel, and which takes into account that (a)
some users will try building bleeding edge kernels on RHEL systems
that might not have the bug fix backported, and it would be nice if
they don't get a buggy compiled kernel, and (b) once the bug fix is
backported, companies like Red Hat would prefer that the workaround
gets disabled to avoid the side effects for things like Systemtap?

Hopefully such a feature will only be needed Very, VERY, *VERY*
rarely, but when the need arises, it's nice to have.

Regards,

						- Ted