From owner-freebsd-arch@FreeBSD.ORG Tue Aug 25 14:23:03 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A90106568C for ; Tue, 25 Aug 2009 14:23:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB118FC2E for ; Tue, 25 Aug 2009 14:23:03 +0000 (UTC) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n7PCV4E4028243 for ; Tue, 25 Aug 2009 22:31:04 +1000 Received: from c122-106-152-1.carlnfd1.nsw.optusnet.com.au (c122-106-152-1.carlnfd1.nsw.optusnet.com.au [122.106.152.1]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n7PCUpFL020967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2009 22:30:52 +1000 Date: Tue, 25 Aug 2009 22:30:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Marcel Moolenaar In-Reply-To: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> Message-ID: <20090825205358.A40622@delplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , arch@FreeBSD.org Subject: Re: mtx_lock_do_what_i_mean() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:23:03 -0000 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