apart from the '--'/'++' bug i can see another bug in your patch:
On Tue, 14 Mar 2000, Andrea Arcangeli wrote:
> +#ifdef __SMP__
> + movl processor(%ebx),%eax
> + shll $5,%eax
> + movl SYMBOL_NAME(irq_stat)(,%eax),%ecx
> + orl SYMBOL_NAME(irq_stat)+4(,%eax),%ecx
> +#else
> + movl SYMBOL_NAME(irq_stat),%ecx
> + orl SYMBOL_NAME(irq_stat)+4,%ecx
> +#endif
> + cmpl $0,%ecx
> + jne restore_all
> + jmp ret_with_reschedule
no, we do not want to execute signal code in that context. I've
intentionally avoided this. Think about it, the signal handler should not
be executed now because the eg. interrupted memcpy() in the middle of an
(otherwise uninterruptible) is not really intended to return to user-space
anywhere. It does work technically to a certain degree, but jumping to
ret_with_reschedule is just asking for trouble - unbounded kernel-stack
recursion for example, and i think some security holes are possible as
well.
> FYI: I got now a crash with such patch applyed. Precisely the below
> BUG triggered (in smp.c smp_invalidate_interrupt):
i havent seen any crash with preemptive-2.3.52-B7. (The only crashes i
ever got were the controlled asserts in preempt_on(), checking for
TASK_RUNNING.) Could you check out B7, can you see any crash with that
one?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:27 EST