[lkml]   [2010]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] jump label: disable due to compiler bug
    * H. Peter Anvin ( 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.



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

     \ /
      Last update: 2010-10-29 23:25    [W:0.024 / U:16.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site