1. 20 Jun, 2007 3 commits
    • Tony Breeds's avatar
      [POWERPC] Fix powermac late initcall to only run on powermac · c5f226c7
      Tony Breeds authored
      Current ppc64_defconfig kernel fails to boot on iSeries, dying with:
      
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc00000000071b258
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=32 iSeries
      <snip>
      NIP [c00000000071b258] .iSeries_src_init+0x34/0x64
      LR [c000000000701bb4] .kernel_init+0x1fc/0x3bc
      Call Trace:
      [c000000007d0be30] [0000000000008000] 0x8000 (unreliable)
      [c000000007d0bea0] [c000000000701bb4] .kernel_init+0x1fc/0x3bc
      [c000000007d0bf90] [c0000000000262d4] .kernel_thread+0x4c/0x68
      Instruction dump:
      e922cba8 3880ffff 78840420 f8010010 f821ff91 60000000 e8090000 78095fe3
      4182002c e922cb58 e862cbb0 e9290140 <e8090000> f8410028 7c0903a6 e9690010
      Kernel panic - not syncing: Attempted to kill init!
      
      This happens because some powermac code unconditionally sets
      ppc_md.progress to NULL.  This patch makes sure the powermac late
      initcall is only run on powermac machines.
      Signed-off-by: default avatarTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      c5f226c7
    • Segher Boessenkool's avatar
      [POWERPC] PowerPC: Prevent data exception in kernel space (32-bit) · 9ba4ace3
      Segher Boessenkool authored
      The "is_exec" branch of the protection check in do_page_fault()
      didn't do anything on 32-bit PowerPC.  So if a userland program
      jumps to a page with Linux protection flags "---p", all the tests
      happily fall through, and handle_mm_fault() is called, which in
      turn calls handle_pte_fault(), which calls update_mmu_cache(),
      which goes flush the dcache to a page with no access rights.
      
      Boom.
      
      This fixes it.
      Signed-off-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      9ba4ace3
    • Li Yang's avatar
      [POWERPC] rheap - eliminates internal fragments caused by alignment · 7c8545e9
      Li Yang authored
      The patch adds fragments caused by rh_alloc_align() back to free list, instead
      of allocating the whole chunk of memory.  This will greatly improve memory
      utilization managed by rheap.
      
      It solves MURAM not enough problem with 3 UCCs enabled on MPC8323.
      Signed-off-by: default avatarLi Yang <leoli@freescale.com>
      Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> 
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      7c8545e9
  2. 19 Jun, 2007 16 commits
  3. 18 Jun, 2007 7 commits
    • Linus Torvalds's avatar
      Fix possible runqueue lock starvation in wait_task_inactive() · fa490cfd
      Linus Torvalds authored
      Miklos Szeredi reported very long pauses (several seconds, sometimes
      more) on his T60 (with a Core2Duo) which he managed to track down to
      wait_task_inactive()'s open-coded busy-loop.
      
      He observed that an interrupt on one core tries to acquire the
      runqueue-lock but does not succeed in doing so for a very long time -
      while wait_task_inactive() on the other core loops waiting for the first
      core to deschedule a task (which it wont do while spinning in an
      interrupt handler).
      
      This rewrites wait_task_inactive() to do all its waiting optimistically
      without any locks taken at all, and then just double-check the end
      result with the proper runqueue lock held over just a very short
      section.  If there were races in the optimistic wait, of a preemption
      event scheduled the process away, we simply re-synchronize, and start
      over.
      
      So the code now looks like this:
      
      	repeat:
      		/* Unlocked, optimistic looping! */
      		rq = task_rq(p);
      		while (task_running(rq, p))
      			cpu_relax();
      
      		/* Get the *real* values */
      		rq = task_rq_lock(p, &flags);
      		running = task_running(rq, p);
      		array = p->array;
      		task_rq_unlock(rq, &flags);
      
      		/* Check them.. */
      		if (unlikely(running)) {
      			cpu_relax();
      			goto repeat;
      		}
      
      		/* Preempted away? Yield if so.. */
      		if (unlikely(array)) {
      			yield();
      			goto repeat;
      		}
      
      Basically, that first "while()" loop is done entirely without any
      locking at all (and doesn't check for the case where the target process
      might have been preempted away), and so it's possibly "incorrect", but
      we don't really care.  Both the runqueue used, and the "task_running()"
      check might be the wrong tests, but they won't oops - they just mean
      that we could possibly get the wrong results due to lack of locking and
      exit the loop early in the case of a race condition.
      
      So once we've exited the loop, we then get the proper (and careful) rq
      lock, and check the running/runnable state _safely_.  And if it turns
      out that our quick-and-dirty and unsafe loop was wrong after all, we
      just go back and try it all again.
      
      (The patch also adds a lot of comments, which is the actual bulk of it
      all, to make it more obvious why we can do these things without holding
      the locks).
      
      Thanks to Miklos for all the testing and tracking it down.
      Tested-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fa490cfd
    • Ingo Molnar's avatar
      sched: fix SysRq-N (normalize RT tasks) · a0f98a1c
      Ingo Molnar authored
      Gene Heskett reported the following problem while testing CFS: SysRq-N
      is not always effective in normalizing tasks back to SCHED_OTHER.
      
      The reason for that turns out to be the following bug:
      
       - normalize_rt_tasks() uses for_each_process() to iterate through all
         tasks in the system.  The problem is, this method does not iterate
         through all tasks, it iterates through all thread groups.
      
      The proper mechanism to enumerate over all threads is to use a
      do_each_thread() + while_each_thread() loop.
      Reported-by: default avatarGene Heskett <gene.heskett@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0f98a1c
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 · 4cc21505
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
        [SCSI] ESP: Don't forget to clear ESP_FLAG_RESETTING.
        [SCSI] fusion: fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive
      4cc21505
    • Benjamin Herrenschmidt's avatar
      Fix signalfd interaction with thread-private signals · caec4e8d
      Benjamin Herrenschmidt authored
      Don't let signalfd dequeue private signals off other threads (in the
      case of things like SIGILL or SIGSEGV, trying to do so would result
      in undefined behaviour on who actually gets the signal, since they
      are force unblocked).
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      caec4e8d
    • Thomas Gleixner's avatar
      Revert "futex_requeue_pi optimization" · bd197234
      Thomas Gleixner authored
      This reverts commit d0aa7a70.
      
      It not only introduced user space visible changes to the futex syscall,
      it is also non-functional and there is no way to fix it proper before
      the 2.6.22 release.
      
      The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went
      unanswered, and unfortunately it turned out that the concept is not
      feasible at all.  It violates the rtmutex semantics badly by introducing
      a virtual owner, which hacks around the coupling of the user-space
      pi_futex and the kernel internal rt_mutex representation.
      
      At the moment the only safe option is to remove it fully as it contains
      user-space visible changes to broken kernel code, which we do not want
      to expose in the 2.6.22 release.
      
      The patch reverts the original patch mostly 1:1, but contains a couple
      of trivial manual cleanups which were necessary due to patches, which
      touched the same area of code later.
      
      Verified against the glibc tests and my own PI futex tests.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarUlrich Drepper <drepper@redhat.com>
      Cc: Pierre Peiffer <pierre.peiffer@bull.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bd197234
    • Paul Mundt's avatar
      sh: oops_enter()/oops_exit() in die(). · 55273982
      Paul Mundt authored
      As Russell helpfully pointed out on linux-arch:
      
      	http://marc.info/?l=linux-arch&m=118208089204630&w=2
      
      We were missing the oops_enter/exit() in the sh die() implementation.
      As we do support lockdep, it's beneficial to add these calls so lockdep
      properly disables itself in the die() case.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      55273982
    • Kaz Kojima's avatar
      sh: Fix restartable syscall arg5 clobbering. · 69a33147
      Kaz Kojima authored
      We use R0 as the 5th argument of syscall.  When the syscall restarts
      after signal handling, we should restore the old value of R0.
      The attached patch does it. Without this patch, I've experienced random
      failures in the situation which signals are issued frequently.
      Signed-off-by: default avatarKaz Kojima <kkojima@rr.iij4u.or.jp>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      69a33147
  4. 17 Jun, 2007 1 commit
  5. 16 Jun, 2007 13 commits