* recursive use of bust_spinlocks()
@ 2007-08-17 10:44 Jan Beulich
0 siblings, 0 replies; only message in thread
From: Jan Beulich @ 2007-08-17 10:44 UTC (permalink / raw)
To: linux-kernel
Various architectures may call bust_spinlocks() recursively (when calling die() in
the context do an unresolved page fault); the function itself, however, doesn't
appear to be meant to be called in this manner. Nevertheless, this doesn't
appear to be a problem as long as bust_spinlocks(0) doesn't get called twice
in a row (otherwise, unblank_screen() may enter the scheduler). However, at
least on i386 die() has been capable of returning (and on other architectures
this should really be that way, too) when notify_die() returns NOTIFY_STOP.
The question now is: Should bust_spinlocks() increment/decrement
oops_in_progress (and kick klogd only when the count drops to zero), or
should we just avoid entering the scheduler by forcibly setting
oops_in_progress to 1 prior to calling unblank_screen(), or should all
architectures currently doing so avoid calling bust_spinlocks() recursively?
Further, many (if not all) architectures seem to have adopted the recursive
die() invocation protection. However, the logic there unconditionally calls
spin_unlock_irqrestore() (besides also allowing for bust_spinlocks() to be
used recursively), instead of undoing just what had been done for the
current function invocation.
Suggestions?
Thanks, Jan
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2007-08-17 10:44 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-17 10:44 recursive use of bust_spinlocks() Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®