linux_dsm_epyc7002/arch/um/os-Linux/signal.c

292 lines
6.3 KiB
C
Raw Normal View History

/*
* Copyright (C) 2004 PathScale, Inc
* Copyright (C) 2004 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
* Licensed under the GPL
*/
#include <stdlib.h>
#include <stdarg.h>
#include <errno.h>
#include <signal.h>
#include <strings.h>
#include "os.h"
#include "sysdep/barrier.h"
#include "sysdep/sigcontext.h"
#include "user.h"
/*
* These are the asynchronous signals. SIGVTALRM and SIGARLM are handled
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
* together under SIGVTALRM_BIT. SIGPROF is excluded because we want to
* be able to profile all of UML, not just the non-critical sections. If
* profiling is not thread-safe, then that is not my problem. We can disable
* profiling when SMP is enabled in that case.
*/
#define SIGIO_BIT 0
#define SIGIO_MASK (1 << SIGIO_BIT)
#define SIGVTALRM_BIT 1
#define SIGVTALRM_MASK (1 << SIGVTALRM_BIT)
#define SIGALRM_BIT 2
#define SIGALRM_MASK (1 << SIGALRM_BIT)
/*
* These are used by both the signal handlers and
[PATCH] uml: fix I/O hang Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 13:07:22 +07:00
* block/unblock_signals. I don't want modifications cached in a
* register - they must go straight to memory.
*/
static volatile int signals_enabled = 1;
static volatile int pending = 0;
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
void sig_handler(int sig, struct sigcontext *sc)
{
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
int enabled;
enabled = signals_enabled;
if (!enabled && (sig == SIGIO)) {
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
pending |= SIGIO_MASK;
return;
}
block_signals();
sig_handler_common_skas(sig, sc);
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
set_signals(enabled);
}
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
static void real_alarm_handler(int sig, struct sigcontext *sc)
{
struct uml_pt_regs regs;
if (sig == SIGALRM)
switch_timers(0);
if (sc != NULL)
copy_sc(&regs, sc);
regs.is_user = 0;
unblock_signals();
timer_handler(sig, &regs);
if (sig == SIGALRM)
switch_timers(1);
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
}
void alarm_handler(int sig, struct sigcontext *sc)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
{
int enabled;
enabled = signals_enabled;
if (!signals_enabled) {
if (sig == SIGVTALRM)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
pending |= SIGVTALRM_MASK;
else pending |= SIGALRM_MASK;
return;
}
block_signals();
real_alarm_handler(sig, sc);
set_signals(enabled);
}
void set_sigstack(void *sig_stack, int size)
{
stack_t stack = ((stack_t) { .ss_flags = 0,
.ss_sp = (__ptr_t) sig_stack,
.ss_size = size - sizeof(void *) });
if (sigaltstack(&stack, NULL) != 0)
panic("enabling signal stack failed, errno = %d\n", errno);
}
void remove_sigstack(void)
{
stack_t stack = ((stack_t) { .ss_flags = SS_DISABLE,
.ss_sp = NULL,
.ss_size = 0 });
if (sigaltstack(&stack, NULL) != 0)
panic("disabling signal stack failed, errno = %d\n", errno);
}
void (*handlers[_NSIG])(int sig, struct sigcontext *sc);
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
void handle_signal(int sig, struct sigcontext *sc)
{
unsigned long pending = 1UL << sig;
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
do {
int nested, bail;
/*
* pending comes back with one bit set for each
* interrupt that arrived while setting up the stack,
* plus a bit for this interrupt, plus the zero bit is
* set if this is a nested interrupt.
* If bail is true, then we interrupted another
* handler setting up the stack. In this case, we
* have to return, and the upper handler will deal
* with this interrupt.
*/
bail = to_irq_stack(&pending);
if (bail)
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
return;
nested = pending & 1;
pending &= ~1;
while ((sig = ffs(pending)) != 0){
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
sig--;
pending &= ~(1 << sig);
(*handlers[sig])(sig, sc);
}
/*
* Again, pending comes back with a mask of signals
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
* that arrived while tearing down the stack. If this
* is non-zero, we just go back, set up the stack
* again, and handle the new interrupts.
*/
if (!nested)
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
pending = from_irq_stack(nested);
} while (pending);
uml: iRQ stacks Add a separate IRQ stack. This differs from i386 in having the entire interrupt run on a separate stack rather than starting on the normal kernel stack and switching over once some preparation has been done. The underlying mechanism, is of course, sigaltstack. Another difference is that interrupts that happen in userspace are handled on the normal kernel stack. These cause a wait wakeup instead of a signal delivery so there is no point in trying to switch stacks for these. There's no other stuff on the stack, so there is no extra stack consumption. This quirk makes it possible to have the entire interrupt run on a separate stack - process preemption (and calls to schedule()) happens on a normal kernel stack. If we enable CONFIG_PREEMPT, this will need to be rethought. The IRQ stack for CPU 0 is declared in the same way as the initial kernel stack. IRQ stacks for other CPUs will be allocated dynamically. An extra field was added to the thread_info structure. When the active thread_info is copied to the IRQ stack, the real_thread field points back to the original stack. This makes it easy to tell where to copy the thread_info struct back to when the interrupt is finished. It also serves as a marker of a nested interrupt. It is NULL for the first interrupt on the stack, and non-NULL for any nested interrupts. Care is taken to behave correctly if a second interrupt comes in when the thread_info structure is being set up or taken down. I could just disable interrupts here, but I don't feel like giving up any of the performance gained by not flipping signals on and off. If an interrupt comes in during these critical periods, the handler can't run because it has no idea what shape the stack is in. So, it sets a bit for its signal in a global mask and returns. The outer handler will deal with this signal itself. Atomicity is had with xchg. A nested interrupt that needs to bail out will xchg its signal mask into pending_mask and repeat in case yet another interrupt hit at the same time, until the mask stabilizes. The outermost interrupt will set up the thread_info and xchg a zero into pending_mask when it is done. At this point, nested interrupts will look at ->real_thread and see that no setup needs to be done. They can just continue normally. Similar care needs to be taken when exiting the outer handler. If another interrupt comes in while it is copying the thread_info, it will drop a bit into pending_mask. The outer handler will check this and if it is non-zero, will loop, set up the stack again, and handle the interrupt. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:22:34 +07:00
}
extern void hard_handler(int sig);
void set_handler(int sig, void (*handler)(int), int flags, ...)
{
struct sigaction action;
va_list ap;
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
sigset_t sig_mask;
int mask;
handlers[sig] = (void (*)(int, struct sigcontext *)) handler;
action.sa_handler = hard_handler;
sigemptyset(&action.sa_mask);
va_start(ap, flags);
while ((mask = va_arg(ap, int)) != -1)
sigaddset(&action.sa_mask, mask);
va_end(ap);
action.sa_flags = flags;
action.sa_restorer = NULL;
if (sigaction(sig, &action, NULL) < 0)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
panic("sigaction failed - errno = %d\n", errno);
sigemptyset(&sig_mask);
sigaddset(&sig_mask, sig);
if (sigprocmask(SIG_UNBLOCK, &sig_mask, NULL) < 0)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
panic("sigprocmask failed - errno = %d\n", errno);
}
int change_sig(int signal, int on)
{
sigset_t sigset, old;
sigemptyset(&sigset);
sigaddset(&sigset, signal);
sigprocmask(on ? SIG_UNBLOCK : SIG_BLOCK, &sigset, &old);
return !sigismember(&old, signal);
}
void block_signals(void)
{
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
signals_enabled = 0;
/*
* This must return with signals disabled, so this barrier
[PATCH] uml: fix I/O hang Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 13:07:22 +07:00
* ensures that writes are flushed out before the return.
* This might matter if gcc figures out how to inline this and
* decides to shuffle this code into the caller.
*/
mb();
}
void unblock_signals(void)
{
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
int save_pending;
if (signals_enabled == 1)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
return;
/*
* We loop because the IRQ handler returns with interrupts off. So,
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
* interrupts may have arrived and we need to re-enable them and
* recheck pending.
*/
while(1) {
/*
* Save and reset save_pending after enabling signals. This
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
* way, pending won't be changed while we're reading it.
*/
signals_enabled = 1;
/*
* Setting signals_enabled and reading pending must
[PATCH] uml: fix I/O hang Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 13:07:22 +07:00
* happen in this order.
*/
mb();
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
save_pending = pending;
if (save_pending == 0) {
/*
* This must return with signals enabled, so
[PATCH] uml: fix I/O hang Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 13:07:22 +07:00
* this barrier ensures that writes are
* flushed out before the return. This might
* matter if gcc figures out how to inline
* this (unlikely, given its size) and decides
* to shuffle this code into the caller.
*/
mb();
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
return;
[PATCH] uml: fix I/O hang Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 13:07:22 +07:00
}
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
pending = 0;
/*
* We have pending interrupts, so disable signals, as the
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
* handlers expect them off when they are called. They will
* be enabled again above.
*/
signals_enabled = 0;
/*
* Deal with SIGIO first because the alarm handler might
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
* schedule, leaving the pending SIGIO stranded until we come
* back here.
*/
if (save_pending & SIGIO_MASK)
sig_handler_common_skas(SIGIO, NULL);
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
if (save_pending & SIGALRM_MASK)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
real_alarm_handler(SIGALRM, NULL);
if (save_pending & SIGVTALRM_MASK)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
real_alarm_handler(SIGVTALRM, NULL);
}
}
int get_signals(void)
{
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
return signals_enabled;
}
int set_signals(int enable)
{
int ret;
if (signals_enabled == enable)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
return enable;
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
ret = signals_enabled;
if (enable)
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
unblock_signals();
else block_signals();
[PATCH] uml: implement soft interrupts This patch implements soft interrupts. Interrupt enabling and disabling no longer map to sigprocmask. Rather, a flag is set indicating whether interrupts may be handled. If a signal comes in and interrupts are marked as OK, then it is handled normally. If interrupts are marked as off, then the signal handler simply returns after noting that a signal needs handling. When interrupts are enabled later on, this pending signals flag is checked, and the IRQ handlers are called at that point. The point of this is to reduce the cost of local_irq_save et al, since they are very much more common than the signals that they are enabling and disabling. Soft interrupts produce a speed-up of ~25% on a kernel build. Subtleties - UML uses sigsetjmp/siglongjmp to switch contexts. sigsetjmp has been wrapped in a save_flags-like macro which remembers the interrupt state at setjmp time, and restores it when it is longjmp-ed back to. The enable_signals function has to loop because the IRQ handler disables interrupts before returning. enable_signals has to return with signals enabled, and signals may come in between the disabling and the return to enable_signals. So, it loops for as long as there are pending signals, ensuring that signals are enabled when it finally returns, and that there are no pending signals that need to be dealt with. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-19 08:42:49 +07:00
return ret;
}