Re: Kernel threads and printf locking question

On Mon, 12 Jan 2004, John Baldwin wrote:

> On Sunday 11 January 2004 03:42 pm, Daan Vreeken [PA4DAN] wrote:

> > What is the current state of printf-locking when called from a kernel
> > thread? Is locking Giant the only possible way to avoid problems on SMP
> > systems, or is there a more fine-grained printf lock available? (on
> > 5.1-RELEASE or -current)
>
> printf really probably does require Giant right now, it just happens to be
> used very often after bootup when SMP is running.

Erm, Giant has nothing to do with printf.  Giant locking might
accidentally prevent concurrent calls to printf, but most callers don't
use it unless they use Giant for other reasons so using it in one
caller would make little difference, and many callers can't use it
because they are interrupt handlers.  Concurrent calls to printf may
cause interleaved output but shouldn't cause panics (in versions of
FreeBSD that have the 2003/06/22 message buffer locking changes).
However, they may cause panics due to broken drivers.  The following
bugs are known:
- syscons console output is non-reentrant, and sometimes (rarely) panics
  if reentered.
- the pty driver is fundamentally incapable of supporting consoles although
  it has pretended to support the TIOCCONS ioctl to set them up for 10-20
  years.  pty console output sometimes (usually) panics if reentered.

Hmm, the syscons problem is quite bad in the SMP case, and not good in
-current generally since printf can be preempted.  Look at sccnputc().
It has no locking whatsover.  Even the spltty() in it is null.  Note
that it can't simply use mutexes since it must work at any time, e.g.,
to print things while single-stepping through it using ddb.

Bruce