1. 24 Aug, 2005 2 commits
    • Paul Jackson's avatar
      [PATCH] cpu_exclusive sched domains build fix · 3725822f
      Paul Jackson authored
      As reported by Paul Mackerras <paulus@samba.org>, the previous patch
      "cpu_exclusive sched domains fix" broke the ppc64 build with
      CONFIC_CPUSET, yielding error messages:
      kernel/cpuset.c: In function 'update_cpu_domains':
      kernel/cpuset.c:648: error: invalid lvalue in unary '&'
      kernel/cpuset.c:648: error: invalid lvalue in unary '&'
      On some arch's, the node_to_cpumask() is a function, returning
      a cpumask_t.  But the for_each_cpu_mask() requires an lvalue mask.
      The following patch fixes this build failure by making a copy
      of the cpumask_t on the stack.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Paul Jackson's avatar
      [PATCH] cpu_exclusive sched domains on partial nodes temp fix · d10689b6
      Paul Jackson authored
      This keeps the kernel/cpuset.c routine update_cpu_domains() from
      invoking the sched.c routine partition_sched_domains() if the cpuset in
      question doesn't fall on node boundaries.
      I have boot tested this on an SN2, and with the help of a couple of ad
      hoc printk's, determined that it does indeed avoid calling the
      partition_sched_domains() routine on partial nodes.
      I did not directly verify that this avoids setting up bogus sched
      domains or avoids the oops that Hawkes saw.
      This patch imposes a silent artificial constraint on which cpusets can
      be used to define dynamic sched domains.
      This patch should allow proceeding with this new feature in 2.6.13 for
      the configurations in which it is useful (node alligned sched domains)
      while avoiding trying to setup sched domains in the less useful cases
      that can cause the kernel corruption and oops.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarDinakar Guniguntala <dino@in.ibm.com>
      Acked-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 09 Aug, 2005 1 commit
    • Paul Jackson's avatar
      [PATCH] cpuset release ABBA deadlock fix · 3077a260
      Paul Jackson authored
      Fix possible cpuset_sem ABBA deadlock if 'notify_on_release' set.
      For a particular usage pattern, creating and destroying cpusets fairly
      frequently using notify_on_release, on a very large system, this deadlock
      can be seen every few days.  If you are not using the cpuset
      notify_on_release feature, you will never see this deadlock.
      The existing code, on task exit (or cpuset deletion) did:
        get cpuset_sem
        if cpuset marked notify_on_release and is ready to release:
          compute cpuset path relative to /dev/cpuset mount point
          call_usermodehelper() forks /sbin/cpuset_release_agent with path
        drop cpuset_sem
      Unfortunately, the fork in call_usermodehelper can allocate memory, and
      allocating memory can require cpuset_sem, if the mems_generation values
      changed in the interim.  This results in an ABBA deadlock, trying to obtain
      cpuset_sem when it is already held by the current task.
      To fix this, I put the cpuset path (which must be computed while holding
      cpuset_sem) in a temporary buffer, to be used in the call_usermodehelper
      call of /sbin/cpuset_release_agent only _after_ dropping cpuset_sem.
      So the new logic is:
        get cpuset_sem
        if cpuset marked notify_on_release and is ready to release:
          compute cpuset path relative to /dev/cpuset mount point
          stash path in kmalloc'd buffer
        drop cpuset_sem
        call_usermodehelper() forks /sbin/cpuset_release_agent with path
        free path
      The sharp eyed reader might notice that this patch does not contain any
      calls to kmalloc.  The existing code in the check_for_release() routine was
      already kmalloc'ing a buffer to hold the cpuset path.  In the old code, it
      just held the buffer for a few lines, over the cpuset_release_agent() call
      that in turn invoked call_usermodehelper().  In the new code, with the
      application of this patch, it returns that buffer via the new char
      **ppathbuf parameter, for later use and freeing in cpuset_release_agent(),
      which is called after cpuset_sem is dropped.  Whereas the old code has just
      one call to cpuset_release_agent(), right in the check_for_release()
      routine, the new code has three calls to cpuset_release_agent(), from the
      various places that a cpuset can be released.
      This patch has been build and booted on SN2, and passed a stress test that
      previously hit the deadlock within a few seconds.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  3. 27 Jul, 2005 1 commit
  4. 25 Jun, 2005 1 commit
  5. 23 Jun, 2005 1 commit
  6. 27 May, 2005 1 commit
    • Paul Jackson's avatar
      [PATCH] cpuset exit NULL dereference fix · 2efe86b8
      Paul Jackson authored
      There is a race in the kernel cpuset code, between the code
      to handle notify_on_release, and the code to remove a cpuset.
      The notify_on_release code can end up trying to access a
      cpuset that has been removed.  In the most common case, this
      causes a NULL pointer dereference from the routine cpuset_path.
      However all manner of bad things are possible, in theory at least.
      The existing code decrements the cpuset use count, and if the
      count goes to zero, processes the notify_on_release request,
      if appropriate.  However, once the count goes to zero, unless we
      are holding the global cpuset_sem semaphore, there is nothing to
      stop another task from immediately removing the cpuset entirely,
      and recycling its memory.
      The obvious fix would be to always hold the cpuset_sem
      semaphore while decrementing the use count and dealing with
      notify_on_release.  However we don't want to force a global
      semaphore into the mainline task exit path, as that might create
      a scaling problem.
      The actual fix is almost as easy - since this is only an issue
      for cpusets using notify_on_release, which the top level big
      cpusets don't normally need to use, only take the cpuset_sem
      for cpusets using notify_on_release.
      This code has been run for hours without a hiccup, while running
      a cpuset create/destroy stress test that could crash the existing
      kernel in seconds.  This patch applies to the current -linus
      git kernel.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Acked-by: default avatarSimon Derr <simon.derr@bull.net>
      Acked-by: default avatarDinakar Guniguntala <dino@in.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  7. 16 Apr, 2005 2 commits
    • Benoit Boissinot's avatar
      [PATCH] cpuset: remove function attribute const · 9a848896
      Benoit Boissinot authored
      gcc-4 warns with
      include/linux/cpuset.h:21: warning: type qualifiers ignored on function
      return type
      cpuset_cpus_allowed is declared with const
      extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
      First const should be __attribute__((const)), but the gcc manual
      explains that:
      "Note that a function that has pointer arguments and examines the data
      pointed to must not be declared const. Likewise, a function that calls a
      non-const function usually must not be const. It does not make sense for
      a const function to return void."
      The following patch remove const from the function declaration.
      Signed-off-by: default avatarBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Acked-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!