Message-ID: <20101029204233.GA28585@Krystal>
Date:	Fri, 29 Oct 2010 16:42:33 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	David Daney <ddaney@...iumnetworks.com>,
	Ingo Molnar <mingo@...e.hu>, Jason Baron <jbaron@...hat.com>,
	rth@...hat.com, tglx@...utronix.de, andi@...stfloor.org,
	roland@...hat.com, masami.hiramatsu.pt@...achi.com,
	fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
	vgoyal@...hat.com, sam@...nborg.org, tony@...eyournoodle.com,
	dsd@...top.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] jump label: disable due to compiler bug

* H. Peter Anvin (hpa@...or.com) wrote:
> On 10/29/2010 10:33 AM, Steven Rostedt wrote:
> >>
> >> Should this knowledge be builtin to the jump label enabling calculus?
> > 
> > No, because we can't trust versions. We never know what home grown gcc a
> > kernel developer is using (and what has been backported or not). Thus
> > the only option is to have a builtin test we can do at compile time to
> > determine if the bug exists or not and decide then.
> > 
> > Note, I'm currently running my last set of patches through ktest. When
> > it finishes (presumably with no issues), I'll post a pull request.
> > 
> 
> I disagree with that assessment.
> 
> We know that if version >= 4.5.2 the problem has been fixed, and that
> for earlier versions we can't know if it's there, so just disable it for
> gcc < 4.5.2.  The fix might have been backported, but it's not a big
> deal if the users of backported compilers don't see the full benefit --
> it's only a problem during a limited time window anyway.

I agree with HPA here. Moreover, we have no hard guarantee that the
automated assembly inspection proposed won't be breaked in the future
caused by changes in gcc. Compiling and running a user-level runtime
test at kernel build time does not work with cross-compilers, and
matching the exact options used for kernel builds might be hard.

I would tend to argue that the added longer-term maintainance burden of
adding such a test is far worse than leaving gcc < 4.5.2 users without
static jump patching, especially given that we have a fallback.

For now, we know that x86_64 works, but the standard setup for x86_32
kernel is broken. What do we do if testing shows that some other
architecture has similar issues ? Add more work-arounds ? At this early
stage, I would simply bump the gcc version dependency forward for all
architectures. Later on, after things have settled and as more and more
architectures are supported, we could deal with arch-specific breakages
on a per-architecture basis.

If this was a showstopper feature, my position would be different. But
the fact that we have been able to wait for gcc to integrate asm gotos
while adding tracepoints shows that it's not crucial in the short term.
We still have to be careful when adding new tracepoints anyway as long
as gcc < 4.5 is still widely used.

Thanks,

Mathieu

> 
> Admittedly it would be nice to have a header file or even a
> configuration file where the gcc version is tested and workarounds are
> centralized; then the backporters could put their own overrides in there.
> 
> 	-hpa

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/

Powered by blists - more mailing lists