Re: [PATCH 2.6.13-stable] cpuset semaphore double trip fix

From: Paul Jackson (pj_at_sgi.com)
Date: 09/10/05

  • Next message: Chris Wright: "Re: Linux 2.6.13.1" 
    Date:	Fri, 9 Sep 2005 20:20:30 -0700
To: Chris Wright <chrisw@osdl.org>

    Chris wrote:
    > Another 'by inspection' patch, perhaps we'll need to update the stable
    > rules, since these can be quite valid fixes, yet typically trigger
    > review replies asking if it's necessary for -stable.

    I'm scratching my head here, trying to figure out what is the
    bottom line of this comment.

    I'm guessing you're saying:

            "By inspection" patches, unless they have something further
            to recommend their inclusion, are not candidates for -stable.

    But intent of your phrase "yet typically trigger review replies ..."
    went right past me ...

    > How unlikely? So unlikely that it's more a theoreitical race, or did
    > you find ways to trigger?

    I don't have a way to trigger it. My guess is that someday, some
    customer will find the right combination of calls, and be able to
    trigger this once every few hours or days. The odds are quite good
    that 2.6.13.* will live out its life before that happens. When it
    happens, it will be a customer doing some serious cpuset manipulations
    on serious big iron.

    > Is this one well-tested, since the fix diverges from upstream?

    Yes - I have a stress test, and some custom kernel tracing, that
    could see the conditions needed to trigger this occurring, just not
    all simultaneously in the necessary small window of vulnerability.

    > And one minor nit, let's just do a real forward declaration of
    > refresh_mems() instead of local to check_for_release().

    Normally, yes. In this case, I was coding to keep the patch as
    localized as possible, and less to optimize the resulting organization
    of the kernel/cpuset.c source file after the patch was applied.

    Given that this patch is unlikely to ever have a life beyond a briefly
    discussed patch today, I guessed right ;) Coding for clarity of the
    patch, not of the source, was arguably the right choice this time.

    Thanks. 

    -- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Chris Wright: "Re: Linux 2.6.13.1"

    Relevant Pages

    • Re: [PATCH] drivers/char/vt possible race
      ... It happens during boot, when userland is playing ... >> mad during boot trying to trigger another problem when this one ... The patch makes sure the vt internal state stays consistent. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: USB OOPS 2.6.25-rc2-git1
      ... that the watchdog is supposed to catch: IAA set, but no IRQ. ... I'll submit some version of this patch for RC3. ... I had an idea about IRQ trigger ...
      (Linux-Kernel)
    • Re: Linuv 2.6.15-rc1
      ... recompiled kernel with a patch below. ... The same story, f/w loading errors ... f/w restarts and then everything is freezing. ... > And see if you can trigger the oops with the included patch applied. ...
      (Linux-Kernel)
    • Re: [PATCH 00 of 31] x86: unification and xen updates
      ... turning irq#0's trigger mode from 'edge' to 'level' in mpparse.c or ioapic.c does wonders to that end;-) ... I think the problem was that the patch changed the ordering so that the %ebp fault test was happening with interrupts disabled, meaning that any fault-in would happen with interrupts disabled. ... Subject: x86: only enable interrupts when kernel state has been set up ... movl TSS_sysenter_sp0,%esp ...
      (Linux-Kernel)
    • Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
      ... Without the patch i can trigger ... > another bigger problem area is the VM - see my patch for details. ... (after applying my patch the latencies ... I discovered I can reliably produce a large XRUN by toggling Caps Lock, ...
      (Linux-Kernel)