Bug 30482

Summary: calcru calls printf while holding a spin lock
Product: Base System Reporter: will <will>
Component: kernAssignee: Remko Lodder <remko>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description will 2001-09-10 10:00:01 UTC 
A machine that previously frequently reported problems with
microuptime() going backwards in calcru started crashing after a
recent update.

I'm just guessing based on the stack trace and the panic message
(and this is the first time I look at anything related to SMPng
locking), but it seems that calcru calls printf which eventually
tries to wake up another process and grab allproc_lock while
sched_lock is held...

This seems like an obvious enough bug that it should not require
further details.

Fix: 

Remove or defer the printf-calls.
Comment 1 Bruce Evans 2001-09-11 15:13:38 UTC 
On Mon, 10 Sep 2001, Ville-Pertti Keinonen wrote:

> >Description:
> A machine that previously frequently reported problems with
> microuptime() going backwards in calcru started crashing after a
> recent update.
>
> I'm just guessing based on the stack trace and the panic message
> (and this is the first time I look at anything related to SMPng
> locking), but it seems that calcru calls printf which eventually
> tries to wake up another process and grab allproc_lock while
> sched_lock is held...
>
> This seems like an obvious enough bug that it should not require
> further details.

This is a bug in printf().  printf() must work when ordinary spinlocks
like sched_lock are held (for debugging).  Known bugs in printf():
- the syscons console driver is not reentrant.  The corresponding
  "microtime() goes backwards" printf() in mi_switch() was ifdefed out
  a long time ago to avoid panicing for this bug.
- the TIOCCONS ioctl causes ordinary printf()s to go to a tty (usually
  a pty).  This can never have worked for printf()s from interrupt
  handlers and now causes a panic instead of random misbehaviour when
  printf() is called with a spinlock held.

Workaround: always use a serial console and don't permit it to be stolen
by TIOCCONS.

Bruce
Comment 2 Remko Lodder freebsd_committer freebsd_triage 2006-12-30 16:46:18 UTC 
State Changed
From-To: open->feedback

Is this still relevant for recent 6.x versions of FreeBSD?
Comment 3 Remko Lodder freebsd_committer freebsd_triage 2006-12-30 16:46:18 UTC 
Responsible Changed
From-To: freebsd-bugs->remko

grab the pr
Comment 4 Remko Lodder freebsd_committer freebsd_triage 2007-01-27 19:01:30 UTC 
State Changed
From-To: feedback->closed

feedback timeout