Hi,
Is the problem actually understood? Do we know what's racing with what?
Given there only ever seems to be a single backtrace involved, as far as
I can tell, it's ttymodem racing with tty_close - can those two
functions alone be locked?
Correct: The only place there tp->t_session is set to NULL is in tty_close().
tp->t_pgrp = NULL;
tp->t_session = NULL;
tp->t_state = 0;
But I've seen this comment on peters page
(http://people.freebsd.org/~peter/smp.html)
At the moment I've hacked all the console code to obtain the scheduler mutex
instead of spltty()'ing all over the place, because in a word: it can't
spltty() any more. It's illegal because the console code may be called at any time (see
the next section). This is a hack because it isn't MP safe against tty
interrupts running on another cpu. Since the current tty interrupt is a fast
interrupt, I'm not sure that we're any worse off (fastints aren't masked by the
cpl anyway).
IMHO it explains why we need the proctree_lock (in early SMP times
scheduler mutex). Maybe this should be replaced with a proper tty subsystem
mutex ...)
After looking at our SMPnewgen Page, Poul Henning and Thomas Moestel
are working on locking the tty subsystem. I'll CC those :-)
Martin
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
