Skip to contentSkip to conversation

make do_signal static on i386

PATCH In review Stephen Rothwell 4 participants 5 messages Oct 9, 2002

lore
Share & tools
lore

Stephen Rothwell

author
#0 lore raw

PATCH 1/1 make do_signal static on i386

Hi Linus,

This patch makes do_signal static in arch/i386/kernel/signal.c which means its declaration can be removed from asm-i386/signal.h which may help Jeff out with UML.

I am not sure whether we need the FASTCALL() or whether the change in the comment in asm-um/signal.h makes sense. (Does UML work on x86_64, yet?)

Signature · 58 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/

diff -ruN 2.5.41-1.715/arch/i386/kernel/signal.c 2.5.41-1.715-si.1/arch/i386/kernel/signal.c
--- 2.5.41-1.715/arch/i386/kernel/signal.c	2002-10-02 11:23:54.000000000 +1000
+++ 2.5.41-1.715-si.1/arch/i386/kernel/signal.c	2002-10-09 17:52:15.000000000 +1000
@@ -27,6 +27,8 @@
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
+static int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
+
 /*
  * Atomically swap in the new signal mask, and wait for a signal.
  */
@@ -545,7 +547,7 @@
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-int do_signal(struct pt_regs *regs, sigset_t *oldset)
+static int do_signal(struct pt_regs *regs, sigset_t *oldset)
 {
 	siginfo_t info;
 	int signr;
diff -ruN 2.5.41-1.715/include/asm-i386/signal.h 2.5.41-1.715-si.1/include/asm-i386/signal.h
--- 2.5.41-1.715/include/asm-i386/signal.h	2002-01-31 07:12:46.000000000 +1100
+++ 2.5.41-1.715-si.1/include/asm-i386/signal.h	2002-10-09 17:54:28.000000000 +1000
@@ -2,7 +2,6 @@
 #define _ASMi386_SIGNAL_H
 
 #include <linux/types.h>
-#include <linux/linkage.h>
 
 /* Avoid too many header ordering problems.  */
 struct siginfo;
@@ -217,9 +216,6 @@
 	return word;
 }
 
-struct pt_regs;
-extern int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
-
 #endif /* __KERNEL__ */
 
 #endif
diff -ruN 2.5.41-1.715/include/asm-um/signal.h 2.5.41-1.715-si.1/include/asm-um/signal.h
--- 2.5.41-1.715/include/asm-um/signal.h	2002-09-16 13:40:57.000000000 +1000
+++ 2.5.41-1.715-si.1/include/asm-um/signal.h	2002-10-09 17:56:20.000000000 +1000
@@ -6,7 +6,7 @@
 #ifndef __UM_SIGNAL_H
 #define __UM_SIGNAL_H
 
-/* Need to kill the do_signal() declaration in the i386 signal.h */
+/* Need to kill the do_signal() declaration in the x86_64 signal.h */
 
 #define do_signal do_signal_renamed
 #include "asm/arch/signal.h"
#1 lore raw
Quoted 3 lines · [email protected] said:

This patch makes do_signal static in arch/i386/kernel/signal.c which means its declaration can be removed from asm-i386/signal.h which may help Jeff out with UML.

Cool, anything which makes the other arch headers more UML-friendly is good.

Quoted 1 line

(Does UML work on x86_64, yet?)

Not yet.

Jeff

#2 lore raw
In reply to Stephen Rothwell

This will cause problems for nano_sleep and clock_nanosleep. These system calls need to call do_signal() in order to meet the POSIX standard which states that they are interrupted only by signals that are delivered to user code. Other signals are not to interrupt the sleep. This is why do_signal() returns this information to the caller.

I suppose one could argue that such functions should be in signal.c, but save for this signal issue the code is common. Seems a waste to support the same code in N platforms.

-g

Quoted 75 lines · Stephen Rothwell

Hi Linus,

This patch makes do_signal static in arch/i386/kernel/signal.c which means its declaration can be removed from asm-i386/signal.h which may help Jeff out with UML.

I am not sure whether we need the FASTCALL() or whether the change in the comment in asm-um/signal.h makes sense. (Does UML work on x86_64, yet?)

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

diff -ruN 2.5.41-1.715/arch/i386/kernel/signal.c 2.5.41-1.715-si.1/arch/i386/kernel/signal.c

arch/i386/kernel/signal.c 2002-10-09 17:52:15.000000000 +1000 renamed from arch/i386/kernel/signal.c 2002-10-02 11:23:54.000000000 +1000 +3 -1
@@ -27,6 +27,8 @@
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
+static int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
+
 /*
  * Atomically swap in the new signal mask, and wait for a signal.
  */

@@ -545,7 +547,7 @@
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-int do_signal(struct pt_regs *regs, sigset_t *oldset)
+static int do_signal(struct pt_regs *regs, sigset_t *oldset)
 {
        siginfo_t info;
        int signr;

diff -ruN 2.5.41-1.715/include/asm-i386/signal.h 2.5.41-1.715-si.1/include/asm-i386/signal.h

include/asm-i386/signal.h 2002-10-09 17:54:28.000000000 +1000 renamed from include/asm-i386/signal.h 2002-01-31 07:12:46.000000000 +1100 +0 -4
@@ -2,7 +2,6 @@
 #define _ASMi386_SIGNAL_H
 
 #include <linux/types.h>
-#include <linux/linkage.h>
 
 /* Avoid too many header ordering problems.  */
 struct siginfo;

@@ -217,9 +216,6 @@
        return word;
 }
 
-struct pt_regs;
-extern int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
-
 #endif /* __KERNEL__ */
 
 #endif

diff -ruN 2.5.41-1.715/include/asm-um/signal.h 2.5.41-1.715-si.1/include/asm-um/signal.h

include/asm-um/signal.h 2002-10-09 17:56:20.000000000 +1000 renamed from include/asm-um/signal.h 2002-09-16 13:40:57.000000000 +1000 +1 -2
@@ -6,7 +6,7 @@
 #ifndef __UM_SIGNAL_H
 #define __UM_SIGNAL_H
 
-/* Need to kill the do_signal() declaration in the i386 signal.h */
+/* Need to kill the do_signal() declaration in the x86_64 signal.h */
 
 #define do_signal do_signal_renamed
 #include "asm/arch/signal.h"
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 5 lines
George Anzinger   [email protected]
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
#3 lore raw
Quoted 8 lines · george anzinger

This will cause problems for nano_sleep and clock_nanosleep. These system calls need to call do_signal() in order to meet the POSIX standard which states that they are interrupted only by signals that are delivered to user code. Other signals are not to interrupt the sleep. This is why do_signal() returns this information to the caller.

Quoted 4 lines

I suppose one could argue that such functions should be in signal.c, but save for this signal issue the code is common. Seems a waste to support the same code in N platforms.

IMO, calling the architecture's do_signal function to handle that is entirely the wrong way to go. They don't even all have the same arguments, and the wrappers hi-res-timers put around sys_nanosleep are hideous.

All of this should be handled correctly in kernel/signal.c, and things like triggering the debugger should be done from there, not duplicated in each platform's signal delivery code.

Ideally we should even trigger the debugger without necessarily knocking the sleeping process out of sleep.

Signature · 2 lines
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
#4 lore raw
Quoted 15 lines · Daniel Jacobowitz
Quoted 8 lines · george anzinger

This will cause problems for nano_sleep and clock_nanosleep. These system calls need to call do_signal() in order to meet the POSIX standard which states that they are interrupted only by signals that are delivered to user code. Other signals are not to interrupt the sleep. This is why do_signal() returns this information to the caller.

Quoted 4 lines

I suppose one could argue that such functions should be in signal.c, but save for this signal issue the code is common. Seems a waste to support the same code in N platforms.

Quoted 4 lines

IMO, calling the architecture's do_signal function to handle that is entirely the wrong way to go. They don't even all have the same arguments, and the wrappers hi-res-timers put around sys_nanosleep are hideous.

Ah, but they should, unless you mean the register structure is different...

Quoted 4 lines

All of this should be handled correctly in kernel/signal.c, and things like triggering the debugger should be done from there, not duplicated in each platform's signal delivery code.

The other side of this nasty mess is getting a handle on the registers. They are all passed differently from the system call stuff in entry.S (or what ever).

Quoted 3 lines

Ideally we should even trigger the debugger without necessarily knocking the sleeping process out of sleep.

Actually it is the other way round, the debugger is triggering the task and asking it to go to a "collection" point.

I would love to do it otherwise. But this is what we have today. And the debugger is not the only case of signals that do not get delivered to user code. For the moment, I would like to make sure the problem can still be addressed. At least today, a solution is possible.

As to how to deliver such events, what is needed is a way to make a task arrive at a known point and to wait there. Sure sounds like a signal to me. I don't see how this can be done with out waking sleepers, but then there are lots of things I don't see :)

Signature · 5 lines
George Anzinger   [email protected]
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml