1. 05 6月, 2005 3 次提交
    • M
      [PATCH] s390: in_interrupt vs. in_atomic · 595bf2aa
      Martin Schwidefsky 提交于
      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: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      595bf2aa
    • B
      [PATCH] s390: uml ptrace fixes · c5c3a6d8
      Bodo Stroesser 提交于
      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: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c5c3a6d8
    • M
      [PATCH] s390: ptrace peek and poke · 778959db
      Martin Schwidefsky 提交于
      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: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      778959db
  2. 01 5月, 2005 7 次提交
  3. 29 4月, 2005 1 次提交
    • [AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls. · 2fd6f58b
      提交于
      We were calling ptrace_notify() after auditing the syscall and arguments,
      but the debugger could have _changed_ them before the syscall was actually
      invoked. Reorder the calls to fix that.
      
      While we're touching ever call to audit_syscall_entry(), we also make it
      take an extra argument: the architecture of the syscall which was made,
      because some architectures allow more than one type of syscall.
      
      Also add an explicit success/failure flag to audit_syscall_exit(), for
      the benefit of architectures which return that in a condition register
      rather than only returning a single register.
      
      Change type of syscall return value to 'long' not 'int'.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      2fd6f58b
  4. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4