The UML_SETJMP macro was requiring its users to pass in a argument which it
could supply itself, since it wasn't used outside that invocation of the
macro.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Clean up the jmpbuf code. Since softints, we no longer use sig_setjmp, so
the UML_SIGSETJMP wrapper now has a misleading name. Also, I forgot to
change the buffers from sigjmp_buf to jmp_buf.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Now that we are doing soft interrupts, there's no point in using sigsetjmp and
siglongjmp. Using setjmp and longjmp saves a sigprocmask on every jump.
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>
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>
Jeff Dike