>>>>> On Wed, 7 Sep 2005 14:47:17 +0100, Ralf Baechle <ralf@xxxxxxxxxxxxxx> said:
ralf> That said, I definately prefer the approach of Atushi's
ralf> suggested fix #2. The other question is why we try to continue
ralf> if delivering a signal failed and we already know that repeated
ralf> attempts would fail again.
The question is for my fix #1 ?
Well, let me explain more. With that fix, things will go like this:
1. The "break" instruction raises a exception.
2. The exception handler queues SIGTRAP(5).
3. dequeue_signal() dequeue a signal with LOWEST number (i.e. SIGTRAP).
4. setup_frame() fails due to bad stack pointer and queues SIGSEGV(11).
5. do_signal() called again (by fix #1)
6. dequeue_signal() dequeue a signal (i.e. SIGSEGV).
7. If SIGSEGV did not have a signal handler, default action (coredump
and exit) is taken. End.
8. If SIGSEGV had a signal handler, setup_frame() fails and queues
SIGSEGV again. It resets SIGSEGV's handler to SIG_DFL.
9. returns to user process (pc unchanged).
10. goto 1. Then ended at 7.
My fix #2 is more generic approach, but even with the fix, the test
program eats CPU until killed by SIGKILL. With my fix #1, the test
program will exit immediately.
So my "which is preferred" question was inappropriate. I had to ask
"#1 or #2 or both or other ?"
---
Atsushi Nemoto
