1. 13 Jun, 2005 2 commits
  2. 12 Jun, 2005 3 commits
  3. 10 Jun, 2005 1 commit
  4. 09 Jun, 2005 7 commits
  5. 08 Jun, 2005 20 commits
  6. 07 Jun, 2005 1 commit
  7. 06 Jun, 2005 1 commit
  8. 04 Jun, 2005 4 commits
    • Gerald Schaefer's avatar
      [PATCH] s390: deadlock in appldata · f26d583e
      Gerald Schaefer authored
      
      
      The system might hang when using appldata_mem with high I/O traffic and a
      large number of devices.  The spinlocks bdev_lock and swaplock are acquired
      via calls to si_meminfo() and si_swapinfo() from a tasklet, i.e.  interrupt
      context, which can lead to a deadlock.  Replace tasklet with work queue.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f26d583e
    • Martin Schwidefsky's avatar
      [PATCH] s390: in_interrupt vs. in_atomic · 595bf2aa
      Martin Schwidefsky authored
      
      
      The condition for no context in do_exception checks for hard and soft
      interrupts by using in_interrupt() but not for preemption.  This is bad for
      the users of __copy_from/to_user_inatomic because the fault handler might call
      schedule although the preemption count is != 0.  Use in_atomic() instead
      in_interrupt().
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      595bf2aa
    • Bodo Stroesser's avatar
      [PATCH] s390: uml ptrace fixes · c5c3a6d8
      Bodo Stroesser authored
      
      
      To make UML build and run on s390, I needed to do these two little
      changes:
      
      1) UML includes some of the subarch's (s390) headers. I had to
         change one of them with the following one-liner, to make this
         compile. AFAICS, this change doesn't break compilation of s390
         itself.
      
      2) UML needs to intercept syscalls via ptrace to invalidate the syscall,
         read syscall's parameters and write the result with the result of
         UML's syscall processing. Also, UML needs to make sure, that the host
         does no syscall restart processing. On i386 for example, this can be
         done by writing -1 to orig_eax on the 2nd syscall interception
         (orig_eax is the syscall number, which after the interception is used
         as a "interrupt was a syscall" flag only.
         Unfortunately, s390 holds syscall number and syscall result in gpr2 and
         its "interrupt was a syscall" flag (trap) is unreachable via ptrace.
         So I changed the host to set trap to -1, if the syscall number is changed
         to an invalid value on the first syscall interception.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c5c3a6d8
    • Martin Schwidefsky's avatar
      [PATCH] s390: ptrace peek and poke · 778959db
      Martin Schwidefsky authored
      
      
      The special cases of peek and poke on acrs[15] and the fpc register are not
      handled correctly.  A poke on acrs[15] will clobber the 4 bytes after the
      access registers in the thread_info structure.  That happens to be the kernel
      stack pointer.  A poke on the fpc with an invalid value is not caught by the
      validity check.  On the next context switch the broken fpc value will cause a
      program check in the kernel.  Improving the checks in peek and poke fixes
      this.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      778959db
  9. 03 Jun, 2005 1 commit
    • Deepak Saxena's avatar
      · 17d82fcc
      Deepak Saxena authored
      
      [PATCH] ARM: 2700/1: Disable IXP2000 IRQs at bootup
      
      Patch from Deepak Saxena
      
      The IXDP2800 bootloader does not disable IRQs before jumping into
      the kernel and this is causing the Grand Unified KGDB to crash
      the system when we do an early call to trap_init() and irq handlers
      have not yet been registered. This patch disables IRQs before we
      jump into the kernel.
      
      Signed-off-by: Deepak Saxena
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      17d82fcc