Date: Thu, 2 Nov 2006 03:11:11 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org, John Birrell <jb@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 genassym.c src/sys/arm/arm genassym.c src/sys/i386/i386 genassym.c src/sys/ia64/ia64 genassym.c src/sys/kern subr_prf.c tty_cons.c src/sys/powerpc/powerpc genassym.c src/sys/sparc64/sparc64 ... Message-ID: <20061102023905.V32204@delplex.bde.org> In-Reply-To: <200611011021.10535.jhb@freebsd.org> References: <200611010454.kA14spYn014613@repoman.freebsd.org> <20061101093550.GK15861@garage.freebsd.pl> <200611011021.10535.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Nov 2006, John Baldwin wrote: > On Wednesday 01 November 2006 04:35, Pawel Jakub Dawidek wrote: >> On Wed, Nov 01, 2006 at 04:54:51AM +0000, John Birrell wrote: >>> jb 2006-11-01 04:54:51 UTC >>> ... >>> Log: >>> Add a cnputs() function to write a string to the console with >>> a lock to prevent interspersed strings written from different CPUs >>> at the same time. >> ... >> What I'd like is a global printf_lock which will allow me to put many >> separate printfs under it and be sure it won't be messed up by other >> CPUs. Having it recursive could also eliminate the need for per-CPU >> buffers, as I don't think we care about performance here. >> >> What do you think? > > Because printf is used for things like panics, I think it needs to be as > robust as possible. I think adding a larger lock like you request would make > it too fragile. It's already quite fragile. Deadlocks seem to be possible in at least the i386 NMI handler now (not just for panics, and even for one type of debugger entry), and were already possible due to similar spinlocking in some console drivers. (Note that NMIs defeat the usual deadlock avoidance method of disabling interrupts on the current CPU.) Most other deadlocks for printf() in panic() seem to be prevented by the bug that panic() doesn't stop other CPUs. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061102023905.V32204>