Date: Tue, 25 Aug 2009 22:30:51 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Ed Schouten <ed@80386.nl>, arch@FreeBSD.org Subject: Re: mtx_lock_do_what_i_mean() Message-ID: <20090825205358.A40622@delplex.bde.org> In-Reply-To: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Aug 2009, Marcel Moolenaar wrote: > On Aug 24, 2009, at 10:40 AM, Ed Schouten wrote: >> As some of you may already know, I'm writing a console driver for >> FreeBSD in my Perforce branch (newcons). What I don't like about console >> devices, but cannot be avoided, is that certain pieces of code need to >> be protected by spinning mutex, instead of default mutexes. This is Certain pieces cannot be protected by any mutex. >> because things like the terminal emulator need to be protected from >> concurrent access, which is likely to happen when printf() by the kernel >> and a write() on a TTY by a userspace process happen at the same time. These are the easy cases. The interesting cases are synchronous i/o in panic and debugger traps (NMI and non-interrupt related traps can also preempt even a spin mutex, but these shouldn't do console i/o except via panic). Mutex locking cannot work in these cases. At best you can ignore the mutex and proceed. In fact, no exclusive or shared locking can work. Atomic operations and reentrant code can work. Hardware and i/o operations to it are fundamentally non-reentrant, so console drivers must arrange for the i/o to clobber the hardware state as little as possible. Once you have made i/o in debugger traps work, other cases are trivial. Debugger trace traps are especially useful for testing reentrancy, since they are deterministic and occur on every instruction. Races that rarely occur in practice are easy to detect by single-stepping (with i/o) through every instruction in upper-level device initialization and i/o routines. > I would approach the problem differently: decouple printf() in the > kernel from anything to which we have a TTY attached. Instead, look > at printf() as a means to write to the message buffer only. Echoing > things that go into the message buffer to the console becomes 1) > optional (yay!), and 2) something you can do by going through the TTY > layer (use a kthread or use a process [syslog]). This is already implemented (TIOCCONS ioctl), but cannot work for serious debugging or panics, since it cannot provide synchronous i/o when it is most needed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090825205358.A40622>