Hi Ingo,
Please accept a patch that fixes the warning message and traceback
seen upon a resume after suspend-to-ram.
The warning message is emitted because
spin_unlock_bh()<--load_debug_registers() is invoked with interrupts
disabled upon 'resume' unlike when invoked at boot-time, and was
reported on LKML here: http://lkml.org/lkml/2009/7/18/145.
This patch modifies load_debug_registers() to block all interrupts and not
just bottom-halves (bottom-halves were blocked in load_debug_registers()
prevent flush_thread_hw_breakpoint() from interfering when invoked from
SoftIRQ context).
Fix traceback seen when resuming after suspend-to-ram
This patch fixes a traceback when resuming after a suspend-to-ram operation.
The traceback warns about entering slowpatch due to a spin_unlock_bh() done
from interrupt context.
Signed-off-by: K.Prasad <[email protected]>
---
kernel/hw_breakpoint.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6-tip/kernel/hw_breakpoint.c
===================================================================
--- linux-2.6-tip.orig/kernel/hw_breakpoint.c
+++ linux-2.6-tip/kernel/hw_breakpoint.c
@@ -80,17 +80,15 @@ void load_debug_registers(void)
unsigned long flags;
struct task_struct *tsk = current;
- spin_lock_bh(&hw_breakpoint_lock);
-
/* Prevent IPIs for new kernel breakpoint updates */
- local_irq_save(flags);
+ spin_lock_irqsave(&hw_breakpoint_lock, flags);
+
arch_update_kernel_hw_breakpoint(NULL);
- local_irq_restore(flags);
if (test_tsk_thread_flag(tsk, TIF_DEBUG))
arch_install_thread_hw_breakpoint(tsk);
- spin_unlock_bh(&hw_breakpoint_lock);
+ spin_unlock_irqrestore(&hw_breakpoint_lock, flags);
}
/*
On Wed, Jul 22, 2009 at 08:41:23PM +0530, K.Prasad wrote:
> Hi Ingo,
> Please accept a patch that fixes the warning message and traceback
> seen upon a resume after suspend-to-ram.
>
> The warning message is emitted because
> spin_unlock_bh()<--load_debug_registers() is invoked with interrupts
> disabled upon 'resume' unlike when invoked at boot-time, and was
> reported on LKML here: http://lkml.org/lkml/2009/7/18/145.
>
> This patch modifies load_debug_registers() to block all interrupts and not
> just bottom-halves (bottom-halves were blocked in load_debug_registers()
> prevent flush_thread_hw_breakpoint() from interfering when invoked from
> SoftIRQ context).
>
> Fix traceback seen when resuming after suspend-to-ram
>
> This patch fixes a traceback when resuming after a suspend-to-ram operation.
> The traceback warns about entering slowpatch due to a spin_unlock_bh() done
> from interrupt context.
>
> Signed-off-by: K.Prasad <[email protected]>
> ---
> kernel/hw_breakpoint.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> Index: linux-2.6-tip/kernel/hw_breakpoint.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/hw_breakpoint.c
> +++ linux-2.6-tip/kernel/hw_breakpoint.c
> @@ -80,17 +80,15 @@ void load_debug_registers(void)
> unsigned long flags;
> struct task_struct *tsk = current;
>
> - spin_lock_bh(&hw_breakpoint_lock);
> -
> /* Prevent IPIs for new kernel breakpoint updates */
> - local_irq_save(flags);
> + spin_lock_irqsave(&hw_breakpoint_lock, flags);
> +
> arch_update_kernel_hw_breakpoint(NULL);
> - local_irq_restore(flags);
>
> if (test_tsk_thread_flag(tsk, TIF_DEBUG))
> arch_install_thread_hw_breakpoint(tsk);
>
> - spin_unlock_bh(&hw_breakpoint_lock);
> + spin_unlock_irqrestore(&hw_breakpoint_lock, flags);
> }
>
> /*
Hmm, this may lead to a state in which lockdep would complain because
your lock is taken as softirq-safe from flush_thread_hw_breakpoint()
and hardirq-safe in load_debug_registers().
Lockdep will think that you have an unsafe state in
flush_thread_hw_breakpoint() because your lock has been taken in
a hardirq-safe fashion elsewhere and therefore can be taken in a
hardirq path.
We know it's safe, but lockdep will warn anyway.
BTW: how is it possible that flush_thread_hw_breakpoint() can be called
from softirq? It can called in a failed fork or any case when a thread
is released. Does such thing sometimes happen in softirq?
Thanks.