Re: [PATCH] Revert "x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT"

[Mike Galbraith <bitbucket@online.de>]

On Sat, 2014-01-04 at 19:18 +0100, Andi Kleen wrote: 
> On Fri, Jan 03, 2014 at 02:55:48PM +0100, Sebastian Andrzej Siewior wrote:
> > where do I start. Let me explain what is going on here. The code
> > sequence
> 
> Yes the IST stacks are needed for correctness, even in more cases than
> the example below. You cannot just disable them, just because you don't
> like them.

You had a better reason than dislike.

<quote> 
From: Andi Kleen <ak@suse.de>
Date: Fri, 3 Jul 2009 08:44:10 -0500
Subject: [PATCH 209/303] x86: Disable IST stacks for debug/int 3/stack fault for PREEMPT_RT

Normally the x86-64 trap handlers for debug/int 3/stack fault run
on a special interrupt stack to make them more robust
when dealing with kernel code.

The PREEMPT_RT kernel can sleep in locks even while allocating
GFP_ATOMIC memory. When one of these trap handlers needs to send
real time signals for ptrace it allocates memory and could then
try to to schedule.  But it is not allowed to schedule on a
IST stack. This can cause warnings and hangs.

This patch disables the IST stacks for these handlers for PREEMPT_RT
kernel. Instead let them run on the normal process stack.

...

A better solution would be to use similar logic as the NMI "paranoid"
path: check if signal is for user space, if yes go back to entry.S, switch stack,
call sync_regs, then do the signal sending etc.

</quote>

Or perhaps tell sleeping locks to spin in annoying spots?  I converted
rt spinlocks globally to preemptible spinning locks (wasn't pretty, but
worked), so seems that could work.

-Mike