[PATCH RT 0/2][RFC] preempt-rt/x86: Handle sending signals from do_trap() by gdb

* [PATCH RT 0/2][RFC] preempt-rt/x86: Handle sending signals from do_trap() by gdb
@ 2012-01-24 18:53 Steven Rostedt
  2012-01-24 18:53 ` [PATCH RT 1/2][RFC] x86: Do not disable preemption in int3 on 32bit Steven Rostedt
  2012-01-24 18:53 ` [PATCH RT 2/2][RFC] preempt-rt/x86: Delay calling singals in int3 Steven Rostedt
  0 siblings, 2 replies; 3+ messages in thread
From: Steven Rostedt @ 2012-01-24 18:53 UTC (permalink / raw)
  To: linux-kernel, linux-rt-users
  Cc: Thomas Gleixner, Carsten Emde, John Kacur, Ingo Molnar,
	Andrew Morton, H. Peter Anvin, Alexander van Heukelum,
	Andi Kleen, Oleg Nesterov, Masami Hiramatsu, Clark Williams,
	Luis Goncalves

Note, this patchset is focused on PREEMPT_RT, but as it affects some of
the x86 code, so I wanted a wider audience. The first patch is not PREEMPT_RT
specific and can go into mainline now.

Here's the issue:

In PREEMPT_RT, every spin_lock() in the kernel turns into a mutex. I wont
go into the details of why this is done, but it helps with latencies, and
we do it in a manner that it just works, except for when it doesn't (like
this patch series is to correct).

When int3 is triggered by gdb, the int3 trap will call do_trap(), and
the do_trap() will call force_sig() to send a SIG_TRAP to the process.

The do_int3() code (as well as do_debug() which gdb also triggers)
calls preempt_conditional_sti() and preemp_conditional_cli() which
will increment/decrement the preempt count to disable preemption, and
will conditionally enable/disable interrupts, depending on if the code
that triggered the trap had interrupts disabled.

Now, that force_sig() that is called grabs a signal spin_lock, which in
PREEMPT_RT happens to be a mutex. If that mutex is under contention, the
task will schedule, and we hit the scheduling while atomic code.

What's worse, in x86_64 the int3 and debug traps switch to a per CPU debug
stack set by the IST. If we schedule with this stack, and another task comes
in and uses the debug stack, the kernel stack can become corrupted and we
crash the system.

On x86_32, the stack is the same as the task's kernel stack and scheduling
should not be an issue. The first patch solves this bug by just not
disabling preemption for x86_32.

The second patch is a bit more involed, and is used to solve the issue on
x86_64. Since we can not simply enable preemption because the current task
is using a per CPU debug stack, we need to postpone the force_sig() and
force_sig_info() calls.

I created a wrapper of these calls with an _rt() extension. This version
will do some checks and if we need to send the SIG_TRAP, it will store the
signal information in the current tasks task_struct and set a new TIF flag
TIF_FORCE_SIG_TRAP.

I added to the paranoid_exit routine in entry_64.S, where it switches the
stack back to the user stack and then enables interrupts and may call schedule
if NEED_RESCHED is set.

In order to not make that code more complex, when the signal needs to be
delayed, the NEED_RESCHED flag is set to force us into that code path.
With the FORCE_SIG_TRAP also set, we can do a check and call a routine to
do the delayed force_sig() after the task's stack is switched back to its
kernel stack and interrupts are reenabled.

Comments? Also anyone see holes in this code?

Thanks,

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread