1. 23 6月, 2018 1 次提交
    • W
      rseq: Avoid infinite recursion when delivering SIGSEGV · 784e0300
      Will Deacon 提交于
      When delivering a signal to a task that is using rseq, we call into
      __rseq_handle_notify_resume() so that the registers pushed in the
      sigframe are updated to reflect the state of the restartable sequence
      (for example, ensuring that the signal returns to the abort handler if
      necessary).
      
      However, if the rseq management fails due to an unrecoverable fault when
      accessing userspace or certain combinations of RSEQ_CS_* flags, then we
      will attempt to deliver a SIGSEGV. This has the potential for infinite
      recursion if the rseq code continuously fails on signal delivery.
      
      Avoid this problem by using force_sigsegv() instead of force_sig(), which
      is explicitly designed to reset the SEGV handler to SIG_DFL in the case
      of a recursive fault. In doing so, remove rseq_signal_deliver() from the
      internal rseq API and have an optional struct ksignal * parameter to
      rseq_handle_notify_resume() instead.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: peterz@infradead.org
      Cc: paulmck@linux.vnet.ibm.com
      Cc: boqun.feng@gmail.com
      Link: https://lkml.kernel.org/r/1529664307-983-1-git-send-email-will.deacon@arm.com
      784e0300
  2. 06 6月, 2018 1 次提交
    • B
      powerpc: Add support for restartable sequences · 8a417c48
      Boqun Feng 提交于
      Call the rseq_handle_notify_resume() function on return to userspace if
      TIF_NOTIFY_RESUME thread flag is set.
      
      Perform fixup on the pre-signal when a signal is delivered on top of a
      restartable sequence critical section.
      Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Chris Lameter <cl@linux.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ben Maurer <bmaurer@fb.com>
      Cc: linux-api@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: https://lkml.kernel.org/r/20180602124408.8430-9-mathieu.desnoyers@efficios.com
      8a417c48
  3. 03 6月, 2018 1 次提交
    • M
      powerpc: Check address limit on user-mode return (TIF_FSCHECK) · 3e378680
      Michael Ellerman 提交于
      set_fs() sets the addr_limit, which is used in access_ok() to
      determine if an address is a user or kernel address.
      
      Some code paths use set_fs() to temporarily elevate the addr_limit so
      that kernel code can read/write kernel memory as if it were user
      memory. That is fine as long as the code can't ever return to
      userspace with the addr_limit still elevated.
      
      If that did happen, then userspace can read/write kernel memory as if
      it were user memory, eg. just with write(2). In case it's not clear,
      that is very bad. It has also happened in the past due to bugs.
      
      Commit 5ea0727b ("x86/syscalls: Check address limit on user-mode
      return") added a mechanism to check the addr_limit value before
      returning to userspace. Any call to set_fs() sets a thread flag,
      TIF_FSCHECK, and if we see that on the return to userspace we go out
      of line to check that the addr_limit value is not elevated.
      
      For further info see the above commit, as well as:
        https://lwn.net/Articles/722267/
        https://bugs.chromium.org/p/project-zero/issues/detail?id=990
      
      Verified to work on 64-bit Book3S using a POC that objdumps the system
      call handler, and a modified lkdtm_CORRUPT_USER_DS() that doesn't kill
      the caller.
      
      Before:
        $ sudo ./test-tif-fscheck
        ...
        0000000000000000 <.data>:
               0:       e1 f7 8a 79     rldicl. r10,r12,30,63
               4:       80 03 82 40     bne     0x384
               8:       00 40 8a 71     andi.   r10,r12,16384
               c:       78 0b 2a 7c     mr      r10,r1
              10:       10 fd 21 38     addi    r1,r1,-752
              14:       08 00 c2 41     beq-    0x1c
              18:       58 09 2d e8     ld      r1,2392(r13)
              1c:       00 00 41 f9     std     r10,0(r1)
              20:       70 01 61 f9     std     r11,368(r1)
              24:       78 01 81 f9     std     r12,376(r1)
              28:       70 00 01 f8     std     r0,112(r1)
              2c:       78 00 41 f9     std     r10,120(r1)
              30:       20 00 82 41     beq     0x50
              34:       a6 42 4c 7d     mftb    r10
      
      After:
      
        $ sudo ./test-tif-fscheck
        Killed
      
      And in dmesg:
        Invalid address limit on user-mode return
        WARNING: CPU: 1 PID: 3689 at ../include/linux/syscalls.h:260 do_notify_resume+0x140/0x170
        ...
        NIP [c00000000001ee50] do_notify_resume+0x140/0x170
        LR [c00000000001ee4c] do_notify_resume+0x13c/0x170
        Call Trace:
          do_notify_resume+0x13c/0x170 (unreliable)
          ret_from_except_lite+0x70/0x74
      
      Performance overhead is essentially zero in the usual case, because
      the bit is checked as part of the existing _TIF_USER_WORK_MASK check.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3e378680
  4. 05 12月, 2017 1 次提交
    • M
      livepatch: send a fake signal to all blocking tasks · 43347d56
      Miroslav Benes 提交于
      Live patching consistency model is of LEAVE_PATCHED_SET and
      SWITCH_THREAD. This means that all tasks in the system have to be marked
      one by one as safe to call a new patched function. Safe means when a
      task is not (sleeping) in a set of patched functions. That is, no
      patched function is on the task's stack. Another clearly safe place is
      the boundary between kernel and userspace. The patching waits for all
      tasks to get outside of the patched set or to cross the boundary. The
      transition is completed afterwards.
      
      The problem is that a task can block the transition for quite a long
      time, if not forever. It could sleep in a set of patched functions, for
      example.  Luckily we can force the task to leave the set by sending it a
      fake signal, that is a signal with no data in signal pending structures
      (no handler, no sign of proper signal delivered). Suspend/freezer use
      this to freeze the tasks as well. The task gets TIF_SIGPENDING set and
      is woken up (if it has been sleeping in the kernel before) or kicked by
      rescheduling IPI (if it was running on other CPU). This causes the task
      to go to kernel/userspace boundary where the signal would be handled and
      the task would be marked as safe in terms of live patching.
      
      There are tasks which are not affected by this technique though. The
      fake signal is not sent to kthreads. They should be handled differently.
      They can be woken up so they leave the patched set and their
      TIF_PATCH_PENDING can be cleared thanks to stack checking.
      
      For the sake of completeness, if the task is in TASK_RUNNING state but
      not currently running on some CPU it doesn't get the IPI, but it would
      eventually handle the signal anyway. Second, if the task runs in the
      kernel (in TASK_RUNNING state) it gets the IPI, but the signal is not
      handled on return from the interrupt. It would be handled on return to
      the userspace in the future when the fake signal is sent again. Stack
      checking deals with these cases in a better way.
      
      If the task was sleeping in a syscall it would be woken by our fake
      signal, it would check if TIF_SIGPENDING is set (by calling
      signal_pending() predicate) and return ERESTART* or EINTR. Syscalls with
      ERESTART* return values are restarted in case of the fake signal (see
      do_signal()). EINTR is propagated back to the userspace program. This
      could disturb the program, but...
      
      * each process dealing with signals should react accordingly to EINTR
        return values.
      * syscalls returning EINTR happen to be quite common situation in the
        system even if no fake signal is sent.
      * freezer sends the fake signal and does not deal with EINTR anyhow.
        Thus EINTR values are returned when the system is resumed.
      
      The very safe marking is done in architectures' "entry" on syscall and
      interrupt/exception exit paths, and in a stack checking functions of
      livepatch.  TIF_PATCH_PENDING is cleared and the next
      recalc_sigpending() drops TIF_SIGPENDING. In connection with this, also
      call klp_update_patch_state() before do_signal(), so that
      recalc_sigpending() in dequeue_signal() can clear TIF_PATCH_PENDING
      immediately and thus prevent a double call of do_signal().
      
      Note that the fake signal is not sent to stopped/traced tasks. Such task
      prevents the patching to finish till it continues again (is not traced
      anymore).
      
      Last, sending the fake signal is not automatic. It is done only when
      admin requests it by writing 1 to signal sysfs attribute in livepatch
      sysfs directory.
      Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: x86@kernel.org
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      43347d56
  5. 13 11月, 2017 1 次提交
    • N
      powerpc/signal: Properly handle return value from uprobe_deny_signal() · 46725b17
      Naveen N. Rao 提交于
      When a uprobe is installed on an instruction that we currently do not
      emulate, we copy the instruction into a xol buffer and single step
      that instruction. If that instruction generates a fault, we abort the
      single stepping before invoking the signal handler. Once the signal
      handler is done, the uprobe trap is hit again since the instruction is
      retried and the process repeats.
      
      We use uprobe_deny_signal() to detect if the xol instruction triggered
      a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the
      signal is not handled until after the single stepping is aborted. In
      this case, uprobe_deny_signal() returns true and get_signal() ends up
      returning 0. However, in do_signal(), we are not looking at the return
      value, but depending on ksig.sig for further action, all with an
      uninitialized ksig that is not touched in this scenario. Fix the same
      by initializing ksig.sig to 0.
      
      Fixes: 129b69df ("powerpc: Use get_signal() signal_setup_done()")
      Cc: stable@vger.kernel.org # v3.17+
      Reported-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      46725b17
  6. 08 3月, 2017 1 次提交
  7. 25 12月, 2016 1 次提交
  8. 04 10月, 2016 1 次提交
    • C
      powerpc: signals: Stop using current in signal code · d1199431
      Cyril Bur 提交于
      Much of the signal code takes a pt_regs on which it operates. Over
      time the signal code has needed to know more about the thread than
      what pt_regs can supply, this information is obtained as needed by
      using 'current'.
      
      This approach is not strictly incorrect however it does mean that
      there is now a hard requirement that the pt_regs being passed around
      does belong to current, this is never checked. A safer approach is for
      the majority of the signal functions to take a task_struct from which
      they can obtain pt_regs and any other information they need. The
      caveat that the task_struct they are passed must be current doesn't go
      away but can more easily be checked for.
      
      Functions called from outside powerpc signal code are passed a pt_regs
      and they can confirm that the pt_regs is that of current and pass
      current to other functions, furthurmore, powerpc signal functions can
      check that the task_struct they are passed is the same as current
      avoiding possible corruption of current (or the task they are passed)
      if this assertion ever fails.
      
      CC: paulus@samba.org
      Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d1199431
  9. 01 3月, 2016 1 次提交
  10. 06 8月, 2014 2 次提交
  11. 20 5月, 2014 1 次提交
    • P
      powerpc: Fix smp_processor_id() in preemptible splat in set_breakpoint · 21f58507
      Paul Gortmaker 提交于
      Currently, on 8641D, which doesn't set CONFIG_HAVE_HW_BREAKPOINT
      we get the following splat:
      
      BUG: using smp_processor_id() in preemptible [00000000] code: login/1382
      caller is set_breakpoint+0x1c/0xa0
      CPU: 0 PID: 1382 Comm: login Not tainted 3.15.0-rc3-00041-g2aafe1a4 #1
      Call Trace:
      [decd5d80] [c0008dc4] show_stack+0x50/0x158 (unreliable)
      [decd5dc0] [c03c6fa0] dump_stack+0x7c/0xdc
      [decd5de0] [c01f8818] check_preemption_disabled+0xf4/0x104
      [decd5e00] [c00086b8] set_breakpoint+0x1c/0xa0
      [decd5e10] [c00d4530] flush_old_exec+0x2bc/0x588
      [decd5e40] [c011c468] load_elf_binary+0x2ac/0x1164
      [decd5ec0] [c00d35f8] search_binary_handler+0xc4/0x1f8
      [decd5ef0] [c00d4ee8] do_execve+0x3d8/0x4b8
      [decd5f40] [c001185c] ret_from_syscall+0x0/0x38
       --- Exception: c01 at 0xfeee554
          LR = 0xfeee7d4
      
      The call path in this case is:
      
      	flush_thread
      	   --> set_debug_reg_defaults
      	     --> set_breakpoint
      	       --> __get_cpu_var
      
      Since preemption is enabled in the cleanup of flush thread, and
      there is no need to disable it, introduce the distinction between
      set_breakpoint and __set_breakpoint, leaving only the flush_thread
      instance as the current user of set_breakpoint.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      21f58507
  12. 15 1月, 2014 1 次提交
    • P
      powerpc: Don't corrupt transactional state when using FP/VMX in kernel · d31626f7
      Paul Mackerras 提交于
      Currently, when we have a process using the transactional memory
      facilities on POWER8 (that is, the processor is in transactional
      or suspended state), and the process enters the kernel and the
      kernel then uses the floating-point or vector (VMX/Altivec) facility,
      we end up corrupting the user-visible FP/VMX/VSX state.  This
      happens, for example, if a page fault causes a copy-on-write
      operation, because the copy_page function will use VMX to do the
      copy on POWER8.  The test program below demonstrates the bug.
      
      The bug happens because when FP/VMX state for a transactional process
      is stored in the thread_struct, we store the checkpointed state in
      .fp_state/.vr_state and the transactional (current) state in
      .transact_fp/.transact_vr.  However, when the kernel wants to use
      FP/VMX, it calls enable_kernel_fp() or enable_kernel_altivec(),
      which saves the current state in .fp_state/.vr_state.  Furthermore,
      when we return to the user process we return with FP/VMX/VSX
      disabled.  The next time the process uses FP/VMX/VSX, we don't know
      which set of state (the current register values, .fp_state/.vr_state,
      or .transact_fp/.transact_vr) we should be using, since we have no
      way to tell if we are still in the same transaction, and if not,
      whether the previous transaction succeeded or failed.
      
      Thus it is necessary to strictly adhere to the rule that if FP has
      been enabled at any point in a transaction, we must keep FP enabled
      for the user process with the current transactional state in the
      FP registers, until we detect that it is no longer in a transaction.
      Similarly for VMX; once enabled it must stay enabled until the
      process is no longer transactional.
      
      In order to keep this rule, we add a new thread_info flag which we
      test when returning from the kernel to userspace, called TIF_RESTORE_TM.
      This flag indicates that there is FP/VMX/VSX state to be restored
      before entering userspace, and when it is set the .tm_orig_msr field
      in the thread_struct indicates what state needs to be restored.
      The restoration is done by restore_tm_state().  The TIF_RESTORE_TM
      bit is set by new giveup_fpu/altivec_maybe_transactional helpers,
      which are called from enable_kernel_fp/altivec, giveup_vsx, and
      flush_fp/altivec_to_thread instead of giveup_fpu/altivec.
      
      The other thing to be done is to get the transactional FP/VMX/VSX
      state from .fp_state/.vr_state when doing reclaim, if that state
      has been saved there by giveup_fpu/altivec_maybe_transactional.
      Having done this, we set the FP/VMX bit in the thread's MSR after
      reclaim to indicate that that part of the state is now valid
      (having been reclaimed from the processor's checkpointed state).
      
      Finally, in the signal handling code, we move the clearing of the
      transactional state bits in the thread's MSR a bit earlier, before
      calling flush_fp_to_thread(), so that we don't unnecessarily set
      the TIF_RESTORE_TM bit.
      
      This is the test program:
      
      /* Michael Neuling 4/12/2013
       *
       * See if the altivec state is leaked out of an aborted transaction due to
       * kernel vmx copy loops.
       *
       *   gcc -m64 htm_vmxcopy.c -o htm_vmxcopy
       *
       */
      
      /* We don't use all of these, but for reference: */
      
      int main(int argc, char *argv[])
      {
      	long double vecin = 1.3;
      	long double vecout;
      	unsigned long pgsize = getpagesize();
      	int i;
      	int fd;
      	int size = pgsize*16;
      	char tmpfile[] = "/tmp/page_faultXXXXXX";
      	char buf[pgsize];
      	char *a;
      	uint64_t aborted = 0;
      
      	fd = mkstemp(tmpfile);
      	assert(fd >= 0);
      
      	memset(buf, 0, pgsize);
      	for (i = 0; i < size; i += pgsize)
      		assert(write(fd, buf, pgsize) == pgsize);
      
      	unlink(tmpfile);
      
      	a = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
      	assert(a != MAP_FAILED);
      
      	asm __volatile__(
      		"lxvd2x 40,0,%[vecinptr] ; " // set 40 to initial value
      		TBEGIN
      		"beq	3f ;"
      		TSUSPEND
      		"xxlxor 40,40,40 ; " // set 40 to 0
      		"std	5, 0(%[map]) ;" // cause kernel vmx copy page
      		TABORT
      		TRESUME
      		TEND
      		"li	%[res], 0 ;"
      		"b	5f ;"
      		"3: ;" // Abort handler
      		"li	%[res], 1 ;"
      		"5: ;"
      		"stxvd2x 40,0,%[vecoutptr] ; "
      		: [res]"=r"(aborted)
      		: [vecinptr]"r"(&vecin),
      		  [vecoutptr]"r"(&vecout),
      		  [map]"r"(a)
      		: "memory", "r0", "r3", "r4", "r5", "r6", "r7");
      
      	if (aborted && (vecin != vecout)){
      		printf("FAILED: vector state leaked on abort %f != %f\n",
      		       (double)vecin, (double)vecout);
      		exit(1);
      	}
      
      	munmap(a, size);
      
      	close(fd);
      
      	printf("PASSED!\n");
      	return 0;
      }
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d31626f7
  13. 01 6月, 2013 1 次提交
    • M
      powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions · 2b3f8e87
      Michael Neuling 提交于
      When in an active transaction that takes a signal, we need to be careful with
      the stack.  It's possible that the stack has moved back up after the tbegin.
      The obvious case here is when the tbegin is called inside a function that
      returns before a tend.  In this case, the stack is part of the checkpointed
      transactional memory state.  If we write over this non transactionally or in
      suspend, we are in trouble because if we get a tm abort, the program counter
      and stack pointer will be back at the tbegin but our in memory stack won't be
      valid anymore.
      
      To avoid this, when taking a signal in an active transaction, we need to use
      the stack pointer from the checkpointed state, rather than the speculated
      state.  This ensures that the signal context (written tm suspended) will be
      written below the stack required for the rollback.  The transaction is aborted
      becuase of the treclaim, so any memory written between the tbegin and the
      signal will be rolled back anyway.
      
      For signals taken in non-TM or suspended mode, we use the
      normal/non-checkpointed stack pointer.
      
      Tested with 64 and 32 bit signals
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2b3f8e87
  14. 14 5月, 2013 2 次提交
  15. 04 2月, 2013 1 次提交
  16. 16 1月, 2013 1 次提交
  17. 10 1月, 2013 1 次提交
  18. 04 11月, 2012 1 次提交
  19. 10 9月, 2012 1 次提交
  20. 05 9月, 2012 1 次提交
    • A
      powerpc: Uprobes port to powerpc · 8b7b80b9
      Ananth N Mavinakayanahalli 提交于
      This is the port of uprobes to powerpc. Usage is similar to x86.
      
      [root@xxxx ~]# ./bin/perf probe -x /lib64/libc.so.6 malloc
      Added new event:
        probe_libc:malloc    (on 0xb4860)
      
      You can now use it in all perf tools, such as:
      
      	perf record -e probe_libc:malloc -aR sleep 1
      
      [root@xxxx ~]# ./bin/perf record -e probe_libc:malloc -aR sleep 20
      [ perf record: Woken up 22 times to write data ]
      [ perf record: Captured and wrote 5.843 MB perf.data (~255302 samples) ]
      [root@xxxx ~]# ./bin/perf report --stdio
      ...
      
          69.05%           tar  libc-2.12.so   [.] malloc
          28.57%            rm  libc-2.12.so   [.] malloc
           1.32%  avahi-daemon  libc-2.12.so   [.] malloc
           0.58%          bash  libc-2.12.so   [.] malloc
           0.28%          sshd  libc-2.12.so   [.] malloc
           0.08%    irqbalance  libc-2.12.so   [.] malloc
           0.05%         bzip2  libc-2.12.so   [.] malloc
           0.04%         sleep  libc-2.12.so   [.] malloc
           0.03%    multipathd  libc-2.12.so   [.] malloc
           0.01%      sendmail  libc-2.12.so   [.] malloc
           0.01%     automount  libc-2.12.so   [.] malloc
      
      The trap_nr addition patch is a prereq.
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8b7b80b9
  21. 02 6月, 2012 6 次提交
  22. 24 5月, 2012 1 次提交
  23. 29 3月, 2012 1 次提交
  24. 07 3月, 2012 1 次提交
    • M
      powerpc: Use set_current_blocked() and block_sigmask() · a2007ce8
      Matt Fleming 提交于
      As described in e6fa16ab ("signal: sigprocmask() should do
      retarget_shared_pending()") the modification of current->blocked is
      incorrect as we need to check whether the signal we're about to block
      is pending in the shared queue.
      
      Also, use the new helper function introduced in commit 5e6292c0
      ("signal: add block_sigmask() for adding sigmask to current->blocked")
      which centralises the code for updating current->blocked after
      successfully delivering a signal and reduces the amount of duplicate
      code across architectures. In the past some architectures got this
      code wrong, so using this helper function should stop that from
      happening again.
      
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a2007ce8
  25. 22 2月, 2012 1 次提交
    • B
      powerpc: Fix various issues with return to userspace · 18b246fa
      Benjamin Herrenschmidt 提交于
      We have a few problems when returning to userspace. This is a
      quick set of fixes for 3.3, I'll look into a more comprehensive
      rework for 3.4. This fixes:
      
       - We kept interrupts soft-disabled when schedule'ing or calling
      do_signal when returning to userspace as a result of a hardware
      interrupt.
      
       - Rename do_signal to do_notify_resume like all other archs (and
      do_signal_pending back to do_signal, which it was before Roland
      changed it).
      
       - Add the missing call to key_replace_session_keyring() to
      do_notify_resume().
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ---
      18b246fa
  26. 23 9月, 2010 1 次提交
  27. 22 6月, 2010 1 次提交
    • K
      powerpc, hw_breakpoint: Enable hw-breakpoints while handling intervening signals · 06532a67
      K.Prasad 提交于
      A signal delivered between a hw_breakpoint_handler() and the
      single_step_dabr_instruction() will not have the breakpoint active
      while the signal handler is running -- the signal delivery will
      set up a new MSR value which will not have MSR_SE set, so we
      won't get the signal step interrupt until and unless the signal
      handler returns (which it may never do).
      
      To fix this, we restore the breakpoint when delivering a signal --
      we clear the MSR_SE bit and set the DABR again.  If the signal
      handler returns, the DABR interrupt will occur again when the
      instruction that we were originally trying to single-step gets
      re-executed.
      
      [Paul Mackerras <paulus@samba.org> pointed out the need to do this.]
      Signed-off-by: NK.Prasad <prasad@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      06532a67
  28. 17 2月, 2010 2 次提交
    • D
      powerpc/booke: Add support for advanced debug registers · 3bffb652
      Dave Kleikamp 提交于
      powerpc/booke: Add support for advanced debug registers
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Based on patches originally written by Torez Smith.
      
      This patch defines context switch and trap related functionality
      for BookE specific Debug Registers. It adds support to ptrace()
      for setting and getting BookE related Debug Registers
      Signed-off-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Cc: Torez Smith  <lnxtorez@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Gibson <dwg@au1.ibm.com>
      Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Sergio Durigan Junior <sergiodj@br.ibm.com>
      Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
      Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3bffb652
    • D
      powerpc/booke: Introduce new CONFIG options for advanced debug registers · 172ae2e7
      Dave Kleikamp 提交于
      powerpc/booke: Introduce new CONFIG options for advanced debug registers
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Introduce new config options to simplify the ifdefs pertaining to the
      advanced debug registers for booke and 40x processors:
      
      CONFIG_PPC_ADV_DEBUG_REGS - boolean: true for dac-based processors
      CONFIG_PPC_ADV_DEBUG_IACS - number of IAC registers
      CONFIG_PPC_ADV_DEBUG_DACS - number of DAC registers
      CONFIG_PPC_ADV_DEBUG_DVCS - number of DVC registers
      CONFIG_PPC_ADV_DEBUG_DAC_RANGE - DAC ranges supported
      
      Beginning conservatively, since I only have the facilities to test 440
      hardware.  I believe all 40x and booke platforms support at least 2 IAC
      and 2 DAC registers.  For 440, 4 IAC and 2 DVC registers are enabled, as
      well as the DAC ranges.
      Signed-off-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Acked-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      172ae2e7
  29. 27 3月, 2009 1 次提交
    • J
      powerpc: Sanitize stack pointer in signal handling code · efbda860
      Josh Boyer 提交于
      On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
      stack pointer passed into the kernel.  Most places handle this correctly, but
      the signal handling code uses the passed value directly for allocating signal
      stack frames.
      
      This fixes the issue by introducing a get_clean_sp function that returns a
      sanitized stack pointer.  For 32-bit tasks on a 64-bit kernel, the stack
      pointer is masked correctly.  In all other cases, the stack pointer is simply
      returned.
      
      Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
      get the properly sanitized stack.  The callers are know to be 32 or 64-bit
      statically.
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      efbda860
  30. 28 7月, 2008 3 次提交