lkml.org 
[lkml]   [1999]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 3 Ooopses in 2.2.3
Date
Hello!

> In the irq a cli will be a nono because we are just returning to usermode
> or whatever and so we'll just restore the interrupts state of the previous
> level. Maybe you want to avoid to get a new nested irq that may start a
> new bh handling inside the envinronment of the first irq?

Not new bh, but new irq. When this function is called irq is already
acked, unmasked and cpu is ready to accept new one. The only protection
is __cli() made by handle_IRQ_event() before exit. __sti() before
run_bottom_halves() breaks it, but we are protected by {soft|hard}irq_locks,
so that only one level of nesting is allowed: it is not good too,
but still acceptable. This function cannot leave interrupts
enabled after it releases irq locks, otherwise recursion will be infinite.
Actually, __cli() is misplaced a bit, better place is immediately
before hardirq_unlock().

> A __cli() in schedule() will be for sure a nono.

It is not very essential, because spin_lock_irq(&runqueue_lock)
will disable them in any case. Probably, __sti() would be useful
before spin_lock(&scheduler_lock). But outside of do_bottom_half.

> It will be interesting to know if it was really a stack depth problem...

When it occurs, then box just reboots instantly or in the worst case,
bottom of task struct corrupted, and kernel decays randomly, but fastly.
I saw task->sig and task->mm corruption. task->files is the next candidate.

Alexey

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.226 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site