> Umm, no. The paths that sends signals to processes (SIGSEGV, SIGBUS etc.)
> have their own handlers and are not dispatched through the usual do_IRQ().
> You'll see that if you follow the interrupt entry code in entry.S.
I' ll take a look... What I need to know is _why_ my kernel locked
yesterday. As Ingo predicted (if I have understood well its sentence too)
I think it was due an irq handler that tried to change current->???.
> This means your patch never touched them. On the other hand it might be
> a good idea to give them their own stacks too - simply to increase locality
> (this needs profiling)
OK. Thinking about the static area, 4kbyte of stack per interrupt x 16
interrupt is not an issue. In a SMP machine instead my last stuff alloc
4kbyte x NR_IRQS x NR_CPUS. This mean 4k x 16(or more, I don' t know how
SMP handle irq) x NR_CPUS. If NR_CPUS is really 32 the stack area would be
really a waste and it would be better to allocate the 4kbyte stack in
request_irq getting a free dynamic page (maybe using some triks to not
allocate 32 dynamic page per interrupt in SMP)...
> Also for Ctrl-C - C-c is of course not send to current. It is send to
> the session leader of the terminal session associated with the tty C-c
^^^^^^^^^^^^^^
Woops, right!!!!
> occured on.
> > Hmm changing current to irq_current inside the irq_handlers sound very
> > simpler and cleaner to me.
>
> Have to check if none of the SMP locking routines (spinlocks etc.) access
> smp_processor_id(), otherwise it'll break. If it turns out that they do
> the fake current is probably a good idea still, because it avoids to define
What does it mean fake current? Which is the good idea?
> interrupt/non interrupt versions then.
I don' t understand very well this but we could always define a
irq_smp_processor_id() that uses irq_current-> instead of current->.
Looking at the current-> implementation I can' t see a way to avoid the
irq_current specific function. irq speicifc functions are ugly but we know
that we are on a interrupt and we can' t do a lot of other things (and
so we must handle a lot of other exception) so they don' t worry me a lot.
Andrea[s] Arcangeli
-
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.altern.org/andrebalsa/doc/lkml-faq.html