2019-08-25 17:49:18 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2015-11-03 00:16:37 +08:00
|
|
|
* Copyright (C) 2015 Anton Ivanov (aivanov@{brocade.com,kot-begemot.co.uk})
|
|
|
|
* Copyright (C) 2015 Thomas Meyer (thomas@m3y3r.de)
|
2005-04-17 06:20:36 +08:00
|
|
|
* Copyright (C) 2004 PathScale, Inc
|
2007-10-16 16:27:00 +08:00
|
|
|
* Copyright (C) 2004 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
2006-01-08 17:01:29 +08:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdarg.h>
|
2007-10-16 16:27:00 +08:00
|
|
|
#include <errno.h>
|
|
|
|
#include <signal.h>
|
2019-08-23 18:44:27 +08:00
|
|
|
#include <string.h>
|
2007-10-16 16:27:00 +08:00
|
|
|
#include <strings.h>
|
2012-10-08 10:27:32 +08:00
|
|
|
#include <as-layout.h>
|
|
|
|
#include <kern_util.h>
|
|
|
|
#include <os.h>
|
|
|
|
#include <sysdep/mcontext.h>
|
2016-06-13 04:03:16 +08:00
|
|
|
#include <um_malloc.h>
|
2017-12-14 10:23:37 +08:00
|
|
|
#include <sys/ucontext.h>
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
#include <timetravel.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-12-30 06:37:31 +08:00
|
|
|
void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
|
2008-02-05 14:31:12 +08:00
|
|
|
[SIGTRAP] = relay_signal,
|
|
|
|
[SIGFPE] = relay_signal,
|
|
|
|
[SIGILL] = relay_signal,
|
|
|
|
[SIGWINCH] = winch,
|
|
|
|
[SIGBUS] = bus_handler,
|
|
|
|
[SIGSEGV] = segv_handler,
|
|
|
|
[SIGIO] = sigio_handler,
|
2015-11-03 00:16:37 +08:00
|
|
|
};
|
2008-02-05 14:31:12 +08:00
|
|
|
|
2013-07-19 17:31:36 +08:00
|
|
|
static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)
|
2008-02-05 14:31:12 +08:00
|
|
|
{
|
2019-01-04 23:38:21 +08:00
|
|
|
struct uml_pt_regs r;
|
2008-02-05 14:31:13 +08:00
|
|
|
int save_errno = errno;
|
2008-02-05 14:31:12 +08:00
|
|
|
|
2019-01-04 23:38:21 +08:00
|
|
|
r.is_user = 0;
|
2008-02-05 14:31:12 +08:00
|
|
|
if (sig == SIGSEGV) {
|
2008-02-05 14:31:13 +08:00
|
|
|
/* For segfaults, we want the data from the sigcontext. */
|
2019-01-04 23:38:21 +08:00
|
|
|
get_regs_from_mc(&r, mc);
|
|
|
|
GET_FAULTINFO_FROM_MC(r.faultinfo, mc);
|
2008-02-05 14:31:13 +08:00
|
|
|
}
|
2008-02-05 14:31:12 +08:00
|
|
|
|
2008-02-05 14:31:13 +08:00
|
|
|
/* enable signals if sig isn't IRQ signal */
|
2019-08-23 18:44:26 +08:00
|
|
|
if ((sig != SIGIO) && (sig != SIGWINCH))
|
2019-08-23 19:16:23 +08:00
|
|
|
unblock_signals_trace();
|
2008-02-05 14:31:12 +08:00
|
|
|
|
2019-01-04 23:38:21 +08:00
|
|
|
(*sig_info[sig])(sig, si, &r);
|
2008-02-05 14:31:12 +08:00
|
|
|
|
|
|
|
errno = save_errno;
|
|
|
|
}
|
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
2007-10-16 16:27:27 +08:00
|
|
|
* These are the asynchronous signals. SIGPROF is excluded because we want to
|
[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 09:42:49 +08:00
|
|
|
* 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)
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
#define SIGALRM_BIT 1
|
|
|
|
#define SIGALRM_MASK (1 << SIGALRM_BIT)
|
[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 09:42:49 +08:00
|
|
|
|
2021-03-05 20:19:54 +08:00
|
|
|
int signals_enabled;
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
#ifdef UML_CONFIG_UML_TIME_TRAVEL_SUPPORT
|
|
|
|
static int signals_blocked;
|
|
|
|
#else
|
2021-08-03 04:40:31 +08:00
|
|
|
#define signals_blocked 0
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
#endif
|
2008-02-05 14:31:16 +08:00
|
|
|
static unsigned int signals_pending;
|
2015-12-21 19:28:02 +08:00
|
|
|
static unsigned int signals_active = 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 09:42:49 +08:00
|
|
|
|
2013-07-19 17:31:36 +08:00
|
|
|
void sig_handler(int sig, struct siginfo *si, mcontext_t *mc)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
int enabled = 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 09:42:49 +08:00
|
|
|
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
if ((signals_blocked || !enabled) && (sig == SIGIO)) {
|
|
|
|
/*
|
|
|
|
* In TT_MODE_EXTERNAL, need to still call time-travel
|
|
|
|
* handlers unless signals are also blocked for the
|
|
|
|
* external time message processing. This will mark
|
|
|
|
* signals_pending by itself (only if necessary.)
|
|
|
|
*/
|
|
|
|
if (!signals_blocked && time_travel_mode == TT_MODE_EXTERNAL)
|
|
|
|
sigio_run_timetravel_handlers();
|
|
|
|
else
|
|
|
|
signals_pending |= SIGIO_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 09:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-08-23 19:16:23 +08:00
|
|
|
block_signals_trace();
|
[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 09:42:49 +08:00
|
|
|
|
2012-08-02 06:49:17 +08:00
|
|
|
sig_handler_common(sig, si, mc);
|
[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 09:42:49 +08:00
|
|
|
|
2021-08-31 15:11:15 +08:00
|
|
|
um_set_signals_trace(enabled);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
static void timer_real_alarm_handler(mcontext_t *mc)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2019-01-04 23:38:21 +08:00
|
|
|
struct uml_pt_regs regs;
|
2007-05-11 13:22:32 +08:00
|
|
|
|
2011-08-19 03:05:09 +08:00
|
|
|
if (mc != NULL)
|
2019-01-04 23:38:21 +08:00
|
|
|
get_regs_from_mc(®s, mc);
|
2019-08-23 18:44:27 +08:00
|
|
|
else
|
|
|
|
memset(®s, 0, sizeof(regs));
|
2019-01-04 23:38:21 +08:00
|
|
|
timer_handler(SIGALRM, NULL, ®s);
|
[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 09:42:49 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
void timer_alarm_handler(int sig, struct siginfo *unused_si, mcontext_t *mc)
|
[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 09:42:49 +08:00
|
|
|
{
|
|
|
|
int enabled;
|
|
|
|
|
|
|
|
enabled = signals_enabled;
|
2007-10-16 16:27:00 +08:00
|
|
|
if (!signals_enabled) {
|
2015-11-03 00:16:37 +08:00
|
|
|
signals_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 09:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-08-23 19:16:23 +08:00
|
|
|
block_signals_trace();
|
[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 09:42:49 +08:00
|
|
|
|
2015-12-21 19:28:02 +08:00
|
|
|
signals_active |= SIGALRM_MASK;
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
timer_real_alarm_handler(mc);
|
2015-12-21 19:28:02 +08:00
|
|
|
|
|
|
|
signals_active &= ~SIGALRM_MASK;
|
|
|
|
|
2021-08-31 15:11:15 +08:00
|
|
|
um_set_signals_trace(enabled);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
void deliver_alarm(void) {
|
|
|
|
timer_alarm_handler(SIGALRM, NULL, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void timer_set_signal_handler(void)
|
2007-10-16 16:27:23 +08:00
|
|
|
{
|
2015-11-03 00:16:37 +08:00
|
|
|
set_handler(SIGALRM);
|
2007-10-16 16:27:23 +08:00
|
|
|
}
|
|
|
|
|
2006-01-08 17:01:29 +08:00
|
|
|
void set_sigstack(void *sig_stack, int size)
|
|
|
|
{
|
2015-06-11 17:29:18 +08:00
|
|
|
stack_t stack = {
|
|
|
|
.ss_flags = 0,
|
|
|
|
.ss_sp = sig_stack,
|
um: Fix stack pointer alignment
GCC assumes that stack is aligned to 16-byte on call sites [1].
Since GCC 8, GCC began using 16-byte aligned SSE instructions to
implement assignments to structs on stack. When
CC_OPTIMIZE_FOR_PERFORMANCE is enabled, this affects
os-Linux/sigio.c, write_sigio_thread:
struct pollfds *fds, tmp;
tmp = current_poll;
Note that struct pollfds is exactly 16 bytes in size.
GCC 8+ generates assembly similar to:
movdqa (%rdi),%xmm0
movaps %xmm0,-0x50(%rbp)
This is an issue, because movaps will #GP if -0x50(%rbp) is not
aligned to 16 bytes [2], and how rbp gets assigned to is via glibc
clone thread_start, then function prologue, going though execution
trace similar to (showing only relevant instructions):
sub $0x10,%rsi
mov %rcx,0x8(%rsi)
mov %rdi,(%rsi)
syscall
pop %rax
pop %rdi
callq *%rax
push %rbp
mov %rsp,%rbp
The stack pointer always points to the topmost element on stack,
rather then the space right above the topmost. On push, the
pointer decrements first before writing to the memory pointed to
by it. Therefore, there is no need to have the stack pointer
pointer always point to valid memory unless the stack is poped;
so the `- sizeof(void *)` in the code is unnecessary.
On the other hand, glibc reserves the 16 bytes it needs on stack
and pops itself, so by the call instruction the stack pointer
is exactly the caller-supplied sp. It then push the 16 bytes of
the return address and the saved stack pointer, so the base
pointer will be 16-byte aligned if and only if the caller
supplied sp is 16-byte aligned. Therefore, the caller must supply
a 16-byte aligned pointer, which `stack + UM_KERN_PAGE_SIZE`
already satisfies.
On a side note, musl is unaffected by this issue because it forces
16 byte alignment via `and $-16,%rsi` in its clone wrapper.
Similarly, glibc i386 is also unaffected because it has
`andl $0xfffffff0, %ecx`.
To reproduce this bug, enable CONFIG_UML_RTC and
CC_OPTIMIZE_FOR_PERFORMANCE. uml_rtc will call
add_sigio_fd which will then cause write_sigio_thread to either go
into segfault loop or panic with "Segfault with no mm".
Similarly, signal stacks will be aligned by the host kernel upon
signal delivery. `- sizeof(void *)` to sigaltstack is
unconventional and extraneous.
On a related note, initialization of longjmp buffers do require
`- sizeof(void *)`. This is to account for the return address
that would have been pushed to the stack at the call site.
The reason for uml to respect 16-byte alignment, rather than
telling GCC to assume 8-byte alignment like the host kernel since
commit d9b0cde91c60 ("x86-64, gcc: Use
-mpreferred-stack-boundary=3 if supported"), is because uml links
against libc. There is no reason to assume libc is also compiled
with that flag and assumes 8-byte alignment rather than 16-byte.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[2] https://c9x.me/x86/html/file_module_x86_id_180.html
Signed-off-by: YiFei Zhu <zhuyifei1999@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-04-20 13:56:10 +08:00
|
|
|
.ss_size = size
|
2015-06-11 17:29:18 +08:00
|
|
|
};
|
2006-01-08 17:01:29 +08:00
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
if (sigaltstack(&stack, NULL) != 0)
|
2006-01-08 17:01:29 +08:00
|
|
|
panic("enabling signal stack failed, errno = %d\n", errno);
|
|
|
|
}
|
|
|
|
|
2020-12-03 03:58:06 +08:00
|
|
|
static void sigusr1_handler(int sig, struct siginfo *unused_si, mcontext_t *mc)
|
|
|
|
{
|
|
|
|
uml_pm_wake();
|
|
|
|
}
|
|
|
|
|
|
|
|
void register_pm_wake_signal(void)
|
|
|
|
{
|
|
|
|
set_handler(SIGUSR1);
|
|
|
|
}
|
|
|
|
|
2013-07-19 17:31:36 +08:00
|
|
|
static void (*handlers[_NSIG])(int sig, struct siginfo *si, mcontext_t *mc) = {
|
2011-08-19 03:04:39 +08:00
|
|
|
[SIGSEGV] = sig_handler,
|
|
|
|
[SIGBUS] = sig_handler,
|
|
|
|
[SIGILL] = sig_handler,
|
|
|
|
[SIGFPE] = sig_handler,
|
|
|
|
[SIGTRAP] = sig_handler,
|
|
|
|
|
|
|
|
[SIGIO] = sig_handler,
|
|
|
|
[SIGWINCH] = sig_handler,
|
2020-12-03 03:58:06 +08:00
|
|
|
[SIGALRM] = timer_alarm_handler,
|
|
|
|
|
|
|
|
[SIGUSR1] = sigusr1_handler,
|
2011-08-19 03:04:39 +08:00
|
|
|
};
|
2006-09-26 14:33:04 +08:00
|
|
|
|
2012-08-02 06:49:17 +08:00
|
|
|
static void hard_handler(int sig, siginfo_t *si, void *p)
|
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 13:22:34 +08:00
|
|
|
{
|
2017-11-15 18:12:39 +08:00
|
|
|
ucontext_t *uc = p;
|
2011-08-19 03:05:09 +08:00
|
|
|
mcontext_t *mc = &uc->uc_mcontext;
|
uml: fix irqstack crash
This patch fixes a crash caused by an interrupt coming in when an IRQ stack
is being torn down. When this happens, handle_signal will loop, setting up
the IRQ stack again because the tearing down had finished, and handling
whatever signals had come in.
However, to_irq_stack returns a mask of pending signals to be handled, plus
bit zero is set if the IRQ stack was already active, and thus shouldn't be
torn down. This causes a problem because when handle_signal goes around
the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
returned mask, faking handle_signal into believing that it shouldn't tear
down the IRQ stack and return thread_info pointers back to their original
values.
This will eventually cause a crash, as the IRQ stack thread_info will
continue pointing to the original task_struct and an interrupt will look
into it after it has been freed.
The fix is to stop passing a signal number into to_irq_stack. Rather, the
pending signals mask is initialized beforehand with the bit for sig already
set. References to sig in to_irq_stack can be replaced with references to
the mask.
[akpm@linux-foundation.org: use UL]
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 13:46:49 +08:00
|
|
|
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 13:22:34 +08: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.
|
|
|
|
*/
|
uml: fix irqstack crash
This patch fixes a crash caused by an interrupt coming in when an IRQ stack
is being torn down. When this happens, handle_signal will loop, setting up
the IRQ stack again because the tearing down had finished, and handling
whatever signals had come in.
However, to_irq_stack returns a mask of pending signals to be handled, plus
bit zero is set if the IRQ stack was already active, and thus shouldn't be
torn down. This causes a problem because when handle_signal goes around
the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
returned mask, faking handle_signal into believing that it shouldn't tear
down the IRQ stack and return thread_info pointers back to their original
values.
This will eventually cause a crash, as the IRQ stack thread_info will
continue pointing to the original task_struct and an interrupt will look
into it after it has been freed.
The fix is to stop passing a signal number into to_irq_stack. Rather, the
pending signals mask is initialized beforehand with the bit for sig already
set. References to sig in to_irq_stack can be replaced with references to
the mask.
[akpm@linux-foundation.org: use UL]
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 13:46:49 +08:00
|
|
|
bail = to_irq_stack(&pending);
|
2007-10-16 16:27:00 +08:00
|
|
|
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 13:22:34 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
nested = pending & 1;
|
|
|
|
pending &= ~1;
|
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
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 13:22:34 +08:00
|
|
|
sig--;
|
|
|
|
pending &= ~(1 << sig);
|
2013-07-19 17:31:36 +08:00
|
|
|
(*handlers[sig])(sig, (struct siginfo *)si, mc);
|
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 13:22:34 +08:00
|
|
|
}
|
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* 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 13:22:34 +08: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.
|
|
|
|
*/
|
2007-10-16 16:27:00 +08:00
|
|
|
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 13:22:34 +08:00
|
|
|
pending = from_irq_stack(nested);
|
2007-10-16 16:27:00 +08:00
|
|
|
} 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 13:22:34 +08:00
|
|
|
}
|
|
|
|
|
2011-08-19 03:04:39 +08:00
|
|
|
void set_handler(int sig)
|
2006-01-08 17:01:29 +08:00
|
|
|
{
|
|
|
|
struct sigaction action;
|
2011-08-19 03:04:29 +08:00
|
|
|
int flags = SA_SIGINFO | SA_ONSTACK;
|
[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 09:42:49 +08:00
|
|
|
sigset_t sig_mask;
|
2006-01-08 17:01:29 +08:00
|
|
|
|
2011-08-19 03:03:39 +08:00
|
|
|
action.sa_sigaction = hard_handler;
|
2006-09-26 14:33:04 +08:00
|
|
|
|
2011-08-19 03:04:29 +08:00
|
|
|
/* block irq ones */
|
2006-01-08 17:01:29 +08:00
|
|
|
sigemptyset(&action.sa_mask);
|
2011-08-19 03:04:29 +08:00
|
|
|
sigaddset(&action.sa_mask, SIGIO);
|
|
|
|
sigaddset(&action.sa_mask, SIGWINCH);
|
2015-11-03 00:16:37 +08:00
|
|
|
sigaddset(&action.sa_mask, SIGALRM);
|
2006-09-26 14:33:04 +08:00
|
|
|
|
2008-02-05 14:31:13 +08:00
|
|
|
if (sig == SIGSEGV)
|
|
|
|
flags |= SA_NODEFER;
|
|
|
|
|
2011-08-19 03:04:29 +08:00
|
|
|
if (sigismember(&action.sa_mask, sig))
|
|
|
|
flags |= SA_RESTART; /* if it's an irq signal */
|
|
|
|
|
|
|
|
action.sa_flags = flags;
|
2006-01-08 17:01:29 +08:00
|
|
|
action.sa_restorer = NULL;
|
2007-10-16 16:27:00 +08:00
|
|
|
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 09:42:49 +08:00
|
|
|
panic("sigaction failed - errno = %d\n", errno);
|
|
|
|
|
|
|
|
sigemptyset(&sig_mask);
|
|
|
|
sigaddset(&sig_mask, sig);
|
2007-10-16 16:27:00 +08:00
|
|
|
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 09:42:49 +08:00
|
|
|
panic("sigprocmask failed - errno = %d\n", errno);
|
2006-01-08 17:01:29 +08:00
|
|
|
}
|
|
|
|
|
um: Support suspend to RAM
With all the previous bits in place, we can now also support
suspend to RAM, in the sense that everything is suspended,
not just most, including userspace, processes like in s2idle.
Since um_idle_sleep() now waits forever, we can simply call
that to "suspend" the system.
As before, you can wake it up using SIGUSR1 since we're just
in a pause() call that only needs to return.
In order to implement selective resume from certain devices,
and not have any arbitrary device interrupt wake up, suspend
interrupts by removing SIGIO notification (O_ASYNC) from all
the FDs that are not supposed to wake up the system. However,
swap out the handler so we don't actually handle the SIGIO as
an interrupt.
Since we're in pause(), the mere act of receiving SIGIO wakes
us up, and then after things have been restored enough, re-set
O_ASYNC for all previously suspended FDs, reinstall the proper
SIGIO handler, and send SIGIO to self to process anything that
might now be pending.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-03 03:58:07 +08:00
|
|
|
void send_sigio_to_self(void)
|
|
|
|
{
|
|
|
|
kill(os_getpid(), SIGIO);
|
|
|
|
}
|
|
|
|
|
2006-01-08 17:01:29 +08:00
|
|
|
int change_sig(int signal, int on)
|
|
|
|
{
|
2008-02-05 14:31:16 +08:00
|
|
|
sigset_t sigset;
|
2006-01-08 17:01:29 +08:00
|
|
|
|
|
|
|
sigemptyset(&sigset);
|
|
|
|
sigaddset(&sigset, signal);
|
2008-02-05 14:31:16 +08:00
|
|
|
if (sigprocmask(on ? SIG_UNBLOCK : SIG_BLOCK, &sigset, NULL) < 0)
|
2008-02-05 14:30:35 +08:00
|
|
|
return -errno;
|
2008-02-05 14:31:16 +08:00
|
|
|
|
|
|
|
return 0;
|
2006-01-08 17:01:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
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 09:42:49 +08:00
|
|
|
signals_enabled = 0;
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* 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 14:07:22 +08: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.
|
|
|
|
*/
|
2008-02-05 14:31:09 +08:00
|
|
|
barrier();
|
2006-01-08 17:01:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
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 09:42:49 +08:00
|
|
|
int save_pending;
|
2006-01-08 17:01:29 +08:00
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
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 09:42:49 +08:00
|
|
|
return;
|
2006-01-08 17:01:29 +08:00
|
|
|
|
2019-08-23 19:16:23 +08:00
|
|
|
signals_enabled = 1;
|
2020-12-14 05:18:18 +08:00
|
|
|
#ifdef UML_CONFIG_UML_TIME_TRAVEL_SUPPORT
|
|
|
|
deliver_time_travel_irqs();
|
|
|
|
#endif
|
2019-08-23 19:16:23 +08:00
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* 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 09:42:49 +08:00
|
|
|
* interrupts may have arrived and we need to re-enable them and
|
2008-02-05 14:31:16 +08:00
|
|
|
* recheck signals_pending.
|
[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 09:42:49 +08:00
|
|
|
*/
|
2008-02-08 20:22:08 +08:00
|
|
|
while (1) {
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* Save and reset save_pending after enabling signals. This
|
2008-02-05 14:31:16 +08:00
|
|
|
* way, signals_pending won't be changed while we're reading it.
|
2019-08-23 19:16:23 +08:00
|
|
|
*
|
2008-02-05 14:31:16 +08:00
|
|
|
* Setting signals_enabled and reading signals_pending must
|
2019-08-23 19:16:23 +08:00
|
|
|
* happen in this order, so have the barrier here.
|
[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 14:07:22 +08:00
|
|
|
*/
|
2008-02-05 14:31:09 +08:00
|
|
|
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 14:07:22 +08:00
|
|
|
|
2008-02-05 14:31:16 +08:00
|
|
|
save_pending = signals_pending;
|
2008-02-05 14:31:09 +08:00
|
|
|
if (save_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 09:42:49 +08:00
|
|
|
return;
|
|
|
|
|
2008-02-05 14:31:16 +08:00
|
|
|
signals_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 09:42:49 +08:00
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* 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 09:42:49 +08:00
|
|
|
* handlers expect them off when they are called. They will
|
2019-08-23 19:16:23 +08:00
|
|
|
* be enabled again above. We need to trace this, as we're
|
|
|
|
* expected to be enabling interrupts already, but any more
|
|
|
|
* tracing that happens inside the handlers we call for the
|
|
|
|
* pending signals will mess up the tracing state.
|
[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 09:42:49 +08:00
|
|
|
*/
|
|
|
|
signals_enabled = 0;
|
2019-08-23 19:16:23 +08:00
|
|
|
um_trace_signals_off();
|
[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 09:42:49 +08:00
|
|
|
|
2007-10-16 16:27:00 +08:00
|
|
|
/*
|
|
|
|
* 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 09:42:49 +08:00
|
|
|
* schedule, leaving the pending SIGIO stranded until we come
|
|
|
|
* back here.
|
2012-08-02 06:49:17 +08:00
|
|
|
*
|
|
|
|
* SIGIO's handler doesn't use siginfo or mcontext,
|
|
|
|
* so they can be 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 09:42:49 +08:00
|
|
|
*/
|
2007-10-16 16:27:00 +08:00
|
|
|
if (save_pending & SIGIO_MASK)
|
2012-08-02 06:49:17 +08:00
|
|
|
sig_handler_common(SIGIO, NULL, 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 09:42:49 +08:00
|
|
|
|
2015-12-21 19:28:02 +08:00
|
|
|
/* Do not reenter the handler */
|
|
|
|
|
|
|
|
if ((save_pending & SIGALRM_MASK) && (!(signals_active & SIGALRM_MASK)))
|
2015-11-03 00:16:37 +08:00
|
|
|
timer_real_alarm_handler(NULL);
|
2015-12-21 19:28:02 +08:00
|
|
|
|
|
|
|
/* Rerun the loop only if there is still pending SIGIO and not in TIMER handler */
|
|
|
|
|
|
|
|
if (!(signals_pending & SIGIO_MASK) && (signals_active & SIGALRM_MASK))
|
|
|
|
return;
|
|
|
|
|
2019-08-23 19:16:23 +08:00
|
|
|
/* Re-enable signals and trace that we're doing so. */
|
|
|
|
um_trace_signals_on();
|
|
|
|
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 09:42:49 +08:00
|
|
|
}
|
2006-01-08 17:01:29 +08:00
|
|
|
}
|
|
|
|
|
2021-08-31 15:11:15 +08:00
|
|
|
int um_set_signals(int enable)
|
2006-01-08 17:01:29 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2007-10-16 16:27:00 +08:00
|
|
|
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 09:42:49 +08:00
|
|
|
return enable;
|
2006-01-08 17:01:29 +08: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 09:42:49 +08:00
|
|
|
ret = signals_enabled;
|
2007-10-16 16:27:00 +08:00
|
|
|
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 09:42:49 +08:00
|
|
|
unblock_signals();
|
|
|
|
else block_signals();
|
2006-01-08 17:01:29 +08: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 09:42:49 +08:00
|
|
|
return ret;
|
2006-01-08 17:01:29 +08:00
|
|
|
}
|
2013-09-23 23:38:02 +08:00
|
|
|
|
2021-08-31 15:11:15 +08:00
|
|
|
int um_set_signals_trace(int enable)
|
2019-08-23 19:16:23 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
if (signals_enabled == enable)
|
|
|
|
return enable;
|
|
|
|
|
|
|
|
ret = signals_enabled;
|
|
|
|
if (enable)
|
|
|
|
unblock_signals_trace();
|
|
|
|
else
|
|
|
|
block_signals_trace();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
#ifdef UML_CONFIG_UML_TIME_TRAVEL_SUPPORT
|
|
|
|
void mark_sigio_pending(void)
|
|
|
|
{
|
|
|
|
signals_pending |= SIGIO_MASK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void block_signals_hard(void)
|
|
|
|
{
|
|
|
|
if (signals_blocked)
|
|
|
|
return;
|
|
|
|
signals_blocked = 1;
|
|
|
|
barrier();
|
|
|
|
}
|
|
|
|
|
|
|
|
void unblock_signals_hard(void)
|
|
|
|
{
|
|
|
|
if (!signals_blocked)
|
|
|
|
return;
|
|
|
|
/* Must be set to 0 before we check the pending bits etc. */
|
|
|
|
signals_blocked = 0;
|
|
|
|
barrier();
|
|
|
|
|
|
|
|
if (signals_pending && signals_enabled) {
|
|
|
|
/* this is a bit inefficient, but that's not really important */
|
|
|
|
block_signals();
|
|
|
|
unblock_signals();
|
|
|
|
} else if (signals_pending & SIGIO_MASK) {
|
|
|
|
/* we need to run time-travel handlers even if not enabled */
|
|
|
|
sigio_run_timetravel_handlers();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-09-23 23:38:02 +08:00
|
|
|
int os_is_signal_stack(void)
|
|
|
|
{
|
|
|
|
stack_t ss;
|
|
|
|
sigaltstack(NULL, &ss);
|
|
|
|
|
|
|
|
return ss.ss_flags & SS_ONSTACK;
|
|
|
|
}
|