On Jul 4, 10:22pm, Chris G. Demetriou wrote:
> Subject: Re: spl/ipl stuff
> > There is a recomended order, well a dependancy list. I think it's in
> > the red book, and it's burried in the code, too. But it's burried
> > deep, I'll admit. :-)
>
> take a look at /sys/arch/i386/isa/isa_machdep.c, starting around line
> 280.

Cheers. Thats the information I was after.

> > A number of the spl level stuff is a form of blanket resource lock. spltty
> > locks ALL the tty queues. But a process (or an interrupt handler..) only
> > needs to worry about access to one particular tty queue. Thus the printf's
> > will probably work if they are touching one queue when the process which
> > asserted spltty is touching another.
>
> Uh, kernel printfs aren't supposed to be pushing data on to tty
> queue, they're supposed to be stuffing the data directly out the
> serial port.

Except that as implemented in -current they *do* push data onto the tty queue
(see below).

>
> > > If the above is true and different ports use different spl orderings then
> > > presumably use of printf()/log() in the interrupt routines of generic
drivers
> > > (or anything that can be called by them) is a Bad Thing (tty code
excepted).
> >
> > Documenting things better is good.  [ ... ]
>
> (1) printf()/log() should be safe to use in generic drivers' interrupt
> routines.

They aren't and here is why.

Manipulation of clists and other tty structures are protected by spltty.

If there is a printf() or log() in a driver which can interrupt spltty then the
following chain of events occurs:

kern/subr_prf.c:printf() calls kprintf() with a NULL tty and the flags TOCONS |
TOLOG
or kern/subr_prf.c:log() calls kprintf() with a NULL tty and the flag TOLOG. If
the log is not flagged as open (I assume this means when syslogd is not
running) then it calls kprintf() again with the flag TOCONS.

kern/subr_prf.c:kprintf() calls putchar()

kern/subr_prf.c:putchar() appears to be safe to use provided that the
destination is either the log or the console (via the cnputc() function). The
problem is that if constty is set (eg by ioctl TIOCCONS - used by xconsole
amongst other things) and the tty is NULL then putchar() translates TOCONS into
TOTTY and calls tputchar() with a tty of constty.

kern/tty.c:tputchar() calls ttyoutput()

kern/tty.c:ttyoutput() is Bad News if you are interrupting something running at
spltty().




To summarise:

(1) printf() is only 100% safe if you know that ioctl TIOCCONS will never be
used and nothing else hijacks constty (ie constty == NULL at all times - in
which case we ought to be able to scrap it)

(2) log() is safer than printf() (I assume) because if you are running syslogd
then everything gets funneled through a userland daemon before it reaches the
console tty.

(3) There is a variable called consintr which is defined and set in
kern/subr_prf.c and allegedly controls console interrupt behaviour but a grep
of the entire source tree (including arch dirs) shows that this is never
tested.


If log() and printf() are supposed to be safe then I guess this needs a
send-pr.

Cheers

Rob Black