From owner-freebsd-arch@FreeBSD.ORG Mon Aug 24 11:06:50 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E05E7106568C for ; Mon, 24 Aug 2009 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B50C48FC37 for ; Mon, 24 Aug 2009 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7OB6odf048477 for ; Mon, 24 Aug 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7OB6o8o048473 for freebsd-arch@FreeBSD.org; Mon, 24 Aug 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Aug 2009 11:06:50 GMT Message-Id: <200908241106.n7OB6o8o048473@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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: Mon, 24 Aug 2009 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 24 17:40:51 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 A5652106568B for ; Mon, 24 Aug 2009 17:40:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 46D718FC1A for ; Mon, 24 Aug 2009 17:40:51 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 4C62F1CD58; Mon, 24 Aug 2009 19:40:50 +0200 (CEST) Date: Mon, 24 Aug 2009 19:40:50 +0200 From: Ed Schouten To: arch@FreeBSD.org Message-ID: <20090824174050.GI2829@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8/UBlNHSEJa6utmr" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: 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: Mon, 24 Aug 2009 17:40:51 -0000 --8/UBlNHSEJa6utmr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, 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 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.=20 It's not like the spin locks are held for an insane amount of time, but still, especially when doing things like scrolling the screen buffer, I think using default mutexes would be a lot better. I was thinking, in theory I'd only need to lock the first window of my console device instances with spin locks, because the other windows will never interact with the kernel message/debug console. I was thinking about locking the mutexes and using their lock classes to call the appropriate lock routine, but looking at the source, something tells me this won't work: | void | lock_spin(struct lock_object *lock, int how) | { |=20 | panic("spin locks can only use msleep_spin"); | } So basically I'm sending this message to ask what I should do here. Is there a more elegant way to solve this? --=20 Ed Schouten WWW: http://80386.nl/ --8/UBlNHSEJa6utmr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqS0KIACgkQ52SDGA2eCwVvtgCfTSCbW6Dr2V3QbocPgoClJirk ktkAn18/s6RGmrryHwaZneG45ddBwE0w =6W9J -----END PGP SIGNATURE----- --8/UBlNHSEJa6utmr-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 24 21:05:18 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 1D21510656A8 for ; Mon, 24 Aug 2009 21:05:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE7C8FC2E for ; Mon, 24 Aug 2009 21:05:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOW006K2D4SBL10@asmtp026.mac.com> for arch@FreeBSD.org; Mon, 24 Aug 2009 13:05:17 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090824174050.GI2829@hoeg.nl> Date: Mon, 24 Aug 2009 13:05:16 -0700 Message-id: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> References: <20090824174050.GI2829@hoeg.nl> To: Ed Schouten X-Mailer: Apple Mail (2.1074) Cc: 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: Mon, 24 Aug 2009 21:05:18 -0000 On Aug 24, 2009, at 10:40 AM, Ed Schouten wrote: > Hi all, > > 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 > 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. 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]). Just a thought, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Tue Aug 25 07:31:00 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 3583D1065693 for ; Tue, 25 Aug 2009 07:30:59 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id CE0338FC0C for ; Tue, 25 Aug 2009 07:30:58 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DC9001CD58; Tue, 25 Aug 2009 09:30:57 +0200 (CEST) Date: Tue, 25 Aug 2009 09:30:57 +0200 From: Ed Schouten To: Marcel Moolenaar Message-ID: <20090825073057.GK2829@hoeg.nl> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvuyDaC2GNSBQusT" Content-Disposition: inline In-Reply-To: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Arch 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 07:31:00 -0000 --GvuyDaC2GNSBQusT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Marcel Moolenaar wrote: > 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]). Yeah. That would be a lot better, but that means you still need to have a lot of code to make it work properly w.r.t. kernel panics: - When you're in the kernel debugger, you still need to have this synchronous programming interface to print data and read keyboard input. - In this context, you need to add extra code to flush the buffer before printing=20 I think we could look at this approach somewhere in the future, but better not now. I'd rather not debug debugging interfaces. ;-) --=20 Ed Schouten WWW: http://80386.nl/ --GvuyDaC2GNSBQusT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqTkzEACgkQ52SDGA2eCwVHSgCeK3STy/if3spb2qUB2tVIiYsJ DhIAn3XXhGkASxQMDNjPlHQYWJSJp242 =Kjko -----END PGP SIGNATURE----- --GvuyDaC2GNSBQusT-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 25 08:57:34 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 ACEC9106564A for ; Tue, 25 Aug 2009 08:57:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB078FC12 for ; Tue, 25 Aug 2009 08:57:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7P8vRP4048648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2009 11:57:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7P8vRuW030918; Tue, 25 Aug 2009 11:57:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7P8vQSn030917; Tue, 25 Aug 2009 11:57:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Aug 2009 11:57:26 +0300 From: Kostik Belousov To: Ed Schouten Message-ID: <20090825085726.GP9623@deviant.kiev.zoral.com.ua> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HeirNmDatrwrWTrV" Content-Disposition: inline In-Reply-To: <20090825073057.GK2829@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Arch , Marcel Moolenaar 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 08:57:34 -0000 --HeirNmDatrwrWTrV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 25, 2009 at 09:30:57AM +0200, Ed Schouten wrote: > I think we could look at this approach somewhere in the future, but > better not now. I'd rather not debug debugging interfaces. ;-) Would you use the lock/unlock function pointers in the appropriate structure ? See, for instance, the locking interface in kqueue subsystem, in particular, struct knlist and functions knlist_init and knlist_init_mtx. --HeirNmDatrwrWTrV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqTp3YACgkQC3+MBN1Mb4joyACg1OAfpQEX0OEF0TF8jyQ1ZOcA Fi8AoLuQM0mMyaJD7Qk9y374S3CAz8cY =t+TC -----END PGP SIGNATURE----- --HeirNmDatrwrWTrV-- 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 From owner-freebsd-arch@FreeBSD.ORG Tue Aug 25 18:58:23 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 D4101106568E for ; Tue, 25 Aug 2009 18:58:23 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 89C128FC15 for ; Tue, 25 Aug 2009 18:58:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOY003YR4P9ZC10@asmtp025.mac.com> for arch@freebsd.org; Tue, 25 Aug 2009 11:58:22 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090825073057.GK2829@hoeg.nl> Date: Tue, 25 Aug 2009 11:58:21 -0700 Message-id: References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> To: Ed Schouten X-Mailer: Apple Mail (2.1074) Cc: FreeBSD Arch 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 18:58:23 -0000 On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: > * Marcel Moolenaar wrote: >> 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]). > > Yeah. That would be a lot better, but that means you still need to > have > a lot of code to make it work properly w.r.t. kernel panics: The debugger doesn't call printf(). It calls db_printf(). We already have everything in place to decouple the debugger from the problem and I would definitely not pull it in. The debugger is a problem all by itself... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 06:35:44 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 E27CB106568E for ; Wed, 26 Aug 2009 06:35:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 646288FC14 for ; Wed, 26 Aug 2009 06:35:44 +0000 (UTC) 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 mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n7Q6ZV3J012764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 16:35:32 +1000 Date: Wed, 26 Aug 2009 16:35:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Marcel Moolenaar In-Reply-To: Message-ID: <20090826161941.B41435@delplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , FreeBSD Arch 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: Wed, 26 Aug 2009 06:35:45 -0000 On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: > >> * Marcel Moolenaar wrote: >>> 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]). >> >> Yeah. That would be a lot better, but that means you still need to have >> a lot of code to make it work properly w.r.t. kernel panics: > > The debugger doesn't call printf(). It calls db_printf(). We > already have everything in place to decouple the debugger > from the problem and I would definitely not pull it in. The > debugger is a problem all by itself... Everything is in place to remove 0.1% of the coupling. Debugger i/o still normally goes to the same device as user and kernel i/o, so it is strongly coupled. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 06:57:12 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 066B01065693 for ; Wed, 26 Aug 2009 06:57:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id E71D28FC21 for ; Wed, 26 Aug 2009 06:57:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from [172.24.241.157] (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOZ00MTP1ZANQ30@asmtp028.mac.com> for arch@FreeBSD.org; Tue, 25 Aug 2009 23:57:11 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090826161941.B41435@delplex.bde.org> Date: Tue, 25 Aug 2009 23:57:09 -0700 Message-id: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1074) Cc: Ed Schouten , FreeBSD Arch 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: Wed, 26 Aug 2009 06:57:12 -0000 On Aug 25, 2009, at 11:35 PM, Bruce Evans wrote: > On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > >> On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: >> >>> * Marcel Moolenaar wrote: >>>> 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]). >>> Yeah. That would be a lot better, but that means you still need to >>> have >>> a lot of code to make it work properly w.r.t. kernel panics: >> >> The debugger doesn't call printf(). It calls db_printf(). We >> already have everything in place to decouple the debugger >> from the problem and I would definitely not pull it in. The >> debugger is a problem all by itself... > > Everything is in place to remove 0.1% of the coupling. Debugger i/o > still normally goes to the same device as user and kernel i/o, so it > is strongly coupled. That's a non sequitur. Sharing travel destinations does not mean that you travel together, for example. The fact that currently the console is used by both does not mean there's coupling. In fact, the debugger goes through the low-level console interface, whereas printf() gets redirected eventually to go through the TTY layer. Having printf() not even write to the console does not mean that the debugger cannot keep using the low-level console interfaces... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 12:06:31 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 7CC4F106568F for ; Wed, 26 Aug 2009 12:06:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 14AF78FC27 for ; Wed, 26 Aug 2009 12:06:30 +0000 (UTC) Received: from besplex.bde.org (c122-106-152-1.carlnfd1.nsw.optusnet.com.au [122.106.152.1]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n7QC6KOI007672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2009 22:06:21 +1000 Date: Wed, 26 Aug 2009 22:06:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar In-Reply-To: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> Message-ID: <20090826192646.O10848@besplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , FreeBSD Arch 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: Wed, 26 Aug 2009 12:06:31 -0000 On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > On Aug 25, 2009, at 11:35 PM, Bruce Evans wrote: > >> On Tue, 25 Aug 2009, Marcel Moolenaar wrote: >> >>> On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: >>> >>>> * Marcel Moolenaar wrote: >>>>> 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]). >>>> Yeah. That would be a lot better, but that means you still need to have >>>> a lot of code to make it work properly w.r.t. kernel panics: >>> >>> The debugger doesn't call printf(). It calls db_printf(). We >>> already have everything in place to decouple the debugger >>> from the problem and I would definitely not pull it in. The >>> debugger is a problem all by itself... >> >> Everything is in place to remove 0.1% of the coupling. Debugger i/o >> still normally goes to the same device as user and kernel i/o, so it >> is strongly coupled. > > That's a non sequitur. Sharing travel destinations does > not mean that you travel together, for example. The coupling here occurs at the destination. > The fact that currently the console is used by both does > not mean there's coupling. In fact, the debugger goes > through the low-level console interface, whereas printf() > gets redirected eventually to go through the TTY layer. printf() goes through the low-level console interface in the same way as the debugger in most cases (unless the console has been redirected). > Having printf() not even write to the console does not > mean that the debugger cannot keep using the low-level > console interfaces... It just means that printf() would be slightly broken (no longer synchronous, and unusable in panic()...). It would remove only another 0.1% of the coupling for the low-level console interfaces, since the debugger must keep using them, and the requirements for working with debuggers are so strong that also working in other cases is trivial. Note that strong coupling is simplest here. If debugger i/o is in a separate module then it has a hard time even knowing the interrupted state. One impossibly difficult weakly-coupled case is when normal i/o is done by a propietary X driver using undocumented hardware features from userland, with some undocumented features active at the time of the interrupt. Non-debugger console i/o is also impossibly difficult in this case. FreeBSD doesn't attempt to support it, and uses cn*avail* interfaces to give null i/o and less than null ddb support. With all the i/o in the kernel, it is possible to guess the hardware and driver state by peeking at driver variables and hardware registers. With strong coupling, it is possible to do this robustly. Upper layers must cooperate by recording enough of their state in an atomic way. The coupling in lower layers then consists of using the records and knowing that they are sufficient. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 16:40:02 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 CF189106568B for ; Wed, 26 Aug 2009 16:40:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id B89FA8FC14 for ; Wed, 26 Aug 2009 16:40:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOZ00LIVSYPCC50@asmtp029.mac.com> for arch@freebsd.org; Wed, 26 Aug 2009 09:40:02 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090826192646.O10848@besplex.bde.org> Date: Wed, 26 Aug 2009 09:40:01 -0700 Message-id: References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> <20090826192646.O10848@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1074) Cc: Ed Schouten , FreeBSD Arch 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: Wed, 26 Aug 2009 16:40:03 -0000 On Aug 26, 2009, at 5:06 AM, Bruce Evans wrote: >>> Everything is in place to remove 0.1% of the coupling. Debugger i/o >>> still normally goes to the same device as user and kernel i/o, so it >>> is strongly coupled. >> >> That's a non sequitur. Sharing travel destinations does >> not mean that you travel together, for example. > > The coupling here occurs at the destination. Exactly: that's why I said everything is in place to change the destination of printf(). >> Having printf() not even write to the console does not >> mean that the debugger cannot keep using the low-level >> console interfaces... > > It just means that printf() would be slightly broken (no longer > synchronous, and unusable in panic()...). printf not being synchronous is actually what solves all the complexity. We don't need synchronous output in the normal case. Only for the "broken" case (i.e. kernel panic, no root FS), do we need synchronous output. It's the exceptional case. I belief common sense tells us to optimize for the common case. > Note that strong coupling is simplest here. I disagree. We've had various threads on this topic and they had the same theme: "we have this interlock and it's a problem. Help!" I belief that trying to solve the problem within the existing framework is not the solution, because I belief the framework itself is the problem. Rethinking it from the bottom-up helps to detangle and come up with a good implementation. > If debugger i/o is in a > separate module then it has a hard time even knowing the interrupted > state. One impossibly difficult weakly-coupled case is when normal > i/o is done by a propietary X driver using undocumented hardware > features from userland, with some undocumented features active at the > time of the interrupt. The question is: why try so hard to solve a problem that's specific to a case we all try our best to avoid? Isn't it much easier to say that debugger output and console are not the same so that you can run X on syscons and DDB over a serial interface and if all else fails: dump a kernel core and analyze the state offline. Having an in-kernel debugger is great, but it should be kept at "arms length" as much as possible. The moment you start sharing interfaces or mixing functionality you're setting yourself up for failure: either the debugger does not work in certain cases (running X is a perfect example of how the in-kernel debugger is totally useless) or you complicate the kernel unnecessarily. > Non-debugger console i/o is also impossibly > difficult in this case. FreeBSD doesn't attempt to support it, and > uses cn*avail* interfaces to give null i/o and less than null ddb > support. With all the i/o in the kernel, it is possible to guess the > hardware and driver state by peeking at driver variables and hardware > registers. With strong coupling, it is possible to do this robustly. That's not true. There's no robust way for the kernel debugger to use hardware that is under the console of process space. If anything: output is always interrupted and disrupted by the debugger, so even if the hardware is left in a consistent state, the actual content on the screen may be garbled. > Upper layers must cooperate by recording enough of their state in an > atomic way. The coupling in lower layers then consists of using the > records and knowing that they are sufficient. Upper layers include user space in some cases. The state of the 3D graphics accelerator is not something you want to have to worry about in the kernel. Though, you do want to know the "mode" if you want to write to the frame buffer. Graphical displays is our weakest point and given that there's no interest in fixing it, I can say that no matter what we do in the existing framework we will never have robust behaviour. Just my $0.02 of course... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 22:07:49 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 AEC651065690 for ; Wed, 26 Aug 2009 22:07:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30D408FC27 for ; Wed, 26 Aug 2009 22:07:48 +0000 (UTC) Received: from besplex.bde.org (c122-106-152-1.carlnfd1.nsw.optusnet.com.au [122.106.152.1]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n7QM7ZlC016388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2009 08:07:36 +1000 Date: Thu, 27 Aug 2009 08:07:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar In-Reply-To: Message-ID: <20090827044818.D826@besplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> <20090826192646.O10848@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , FreeBSD Arch 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: Wed, 26 Aug 2009 22:07:49 -0000 On Wed, 26 Aug 2009, Marcel Moolenaar wrote: > On Aug 26, 2009, at 5:06 AM, Bruce Evans wrote: > >>>> Everything is in place to remove 0.1% of the coupling. Debugger i/o >>>> still normally goes to the same device as user and kernel i/o, so it >>>> is strongly coupled. >>> >>> That's a non sequitur. Sharing travel destinations does >>> not mean that you travel together, for example. >> >> The coupling here occurs at the destination. > > Exactly: that's why I said everything is in place to change the > destination of printf(). Except for printf()s in panic(). These can only be redirected to driver(s) similar to working console drivers would need similar complications to work. One thing that could be done now is reducing from multiple active broken console drivers to a single least-broken one for panics and debugging, or at least as a last effort for recursive panics. However, this doesn't help in the usual case where there is only 1 active console driver or in the fairly usual case where the user has only 1 set of console hardware. >>> Having printf() not even write to the console does not >>> mean that the debugger cannot keep using the low-level >>> console interfaces... >> >> It just means that printf() would be slightly broken (no longer >> synchronous, and unusable in panic()...). > > printf not being synchronous is actually what solves all > the complexity. We don't need synchronous output in the > normal case. Only for the "broken" case (i.e. kernel > panic, no root FS), do we need synchronous output. It's > the exceptional case. > > I belief common sense tells us to optimize for the common > case. We're not optimizing, but making the uncommon case actually work. >> Note that strong coupling is simplest here. > > I disagree. We've had various threads on this topic and > they had the same theme: "we have this interlock and it's > a problem. Help!" There is remarkably little understanding of the problem. The interlock is not a problem. It is the state being protected by the interlock that is a problem! A working console driver cannot just blow away the interrupted state, either hardware or software, and it cannot rely on the interrupt state being usable. > I belief that trying to solve the problem within the > existing framework is not the solution, because I belief > the framework itself is the problem. Rethinking it from > the bottom-up helps to detangle and come up with a good > implementation. I've outlined a good solution many times and implemented part of it in FreeBSD and all of it in my debugger's i/o routines: - switch to and from console i/o mode when directed to by cn_dbctl(). Natural switch points for ddb are on entry to and exit from interactive mode. Natural switch points for other i/o are not so clear -- switching for every printf() is too much. - make the switches nest as deep as necessary (3 or 4 levels is enough) - switches involve: on entry: - save all state (hardware and software) not already saved. Here it helps for upper layers to not have much state in the air. Here it is essential for upper layers to have recorded their state in some atomic way. - initialize all state (hardware and software) used by console driver. Here it helps for the upper layers to have initialized most of the state. You can always reinitialize everything, but then restoring the interrupted state will be hard. on exit: - restore as much state (hardware and software) as possible. Except, if the console i/o routines wrote to the same physical console that non-console routines write to, and this physical console is something like a frame buffer, then the something-like-a-frame-buffer state must not be restored, so that you can actually read the output. Debugger frame buffer output should go to a separate virtual console, possibly in a different video mode. If the video mode is not switched, then the hardware part of the switch involves mainly copying the frame buffer out and in. If the video mode is switched, then the switch involves reinitializing lots of hardware. Switching to a fixed mode is probably still simpler than supporting console output in all possible interrupted modes. Writing to a separate virtual console is not so good for non-debugger output, since the output needs to be made visible at some point and switching the console on every printf() is no good. Switching back and forth on every printf() is worst -- it makes the screen flicker, and the output is still invisible most of the time. IIRC, old console drivers (codrv and pcvt) wrote to ttyv0 and forced a switch there. This was inconvenient. It is probably best to always printf() to a separate virtual console (different from the debugger one), and also to the current console if possible and implemented. - after switching to console mode, the actual i/o is trival, at least if you always switch the interrupted mode to a fixed one if the interrupted mode is different. >> If debugger i/o is in a >> separate module then it has a hard time even knowing the interrupted >> state. One impossibly difficult weakly-coupled case is when normal >> i/o is done by a propietary X driver using undocumented hardware >> features from userland, with some undocumented features active at the >> time of the interrupt. > > The question is: why try so hard to solve a problem that's > specific to a case we all try our best to avoid? Isn't it > much easier to say that debugger output and console are not > the same so that you can run X on syscons and DDB over a > serial interface and if all else fails: dump a kernel core > and analyze the state offline. Some users and/or developers don't have or want to set up multiple i/o devices just for consoles. > Having an in-kernel debugger is great, but it should be > kept at "arms length" as much as possible. The moment you > start sharing interfaces or mixing functionality you're > setting yourself up for failure: either the debugger does > not work in certain cases (running X is a perfect example > of how the in-kernel debugger is totally useless) or you > complicate the kernel unnecessarily. Well, once you have working console i/o for debuggers, you almost have it for panic(), and you don't have to worry about printf() from interrupt handlers that interrupt an inadequately locked upper-level i/o routine corrupting the upper level. Syscons' spltty() (and missing) locking was always inadequate for this (it needed to be splhigh() for much the same reasons that it is now a spin mutex, but this is ugly). Working console i/o requires forces you to find most of the inadequate locking and helps find some of it (single-step through the driver until it crashes). >> Non-debugger console i/o is also impossibly >> difficult in this case. FreeBSD doesn't attempt to support it, and >> uses cn*avail* interfaces to give null i/o and less than null ddb >> support. With all the i/o in the kernel, it is possible to guess the >> hardware and driver state by peeking at driver variables and hardware >> registers. With strong coupling, it is possible to do this robustly. > > That's not true. There's no robust way for the kernel debugger > to use hardware that is under the console of process space. > If anything: output is always interrupted and disrupted by the > debugger, so even if the hardware is left in a consistent state, > the actual content on the screen may be garbled. The amount of disruption is hardware-dependent. Losing a couple of characters is unimportant, and is also avoidable for frame buffer type hardware. Switching the console and its mode to avoid disrupting output has been routine in at least userland debuggers for at least 20 years. Userland debuggers have fewer problems doing this since they can't interrupt hardware mode switches, but their switch is still a heavyweight operation. OTOH, kernel debuggers can avoid the mode switch and possibly the console switch in most cases since they are close to the driver (if the driver is entirely in the kernel). >> Upper layers must cooperate by recording enough of their state in an >> atomic way. The coupling in lower layers then consists of using the >> records and knowing that they are sufficient. > > Upper layers include user space in some cases. The state of the > 3D graphics accelerator is not something you want to have to worry > about in the kernel. Though, you do want to know the "mode" if > you want to write to the frame buffer. Graphical displays is our > weakest point and given that there's no interest in fixing it, Yes, I don't want to support any userland graphics driver. > I can say that no matter what we do in the existing framework we > will never have robust behaviour. Actually, it can be made robust (but not working) fairly easily: - clear the device's cn_avail_mask bit while in critical regions. This could be implemented fairly easily using the macro for locking the critical regions. - fix the placement of cnunavailable() in ddb, so that breakpoints in the instruction stream aren't fatal when they are hit while the console is unavailable. - the cn_avail_mask bit is managed by calling cnavail(). It is not very efficient, despite having no locking whatsoever. Fix its locking and try to optimize it. The whole of kern_cons.c has no locking except for broken locking in cnputs(). Normal mutex locking cannot be used, but cnputs() uses it. mtx_trylock() would be robust (but not working) in cnputs(). Accesses to cn_avail_mask need a bit more than atomicity, since there is another avail bit in cn_flags. - fix many other races involving accesses to cn_avail_mask. Oops. there are some that cannot be made robust fairly easily. There is 1 involving checking cnunavail() and acting on its result. This one is mosty dormant. Active ones include cnremove() called from the console control sysctl racing with cnavail() called from upper layers of device drivers that support consoles. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Aug 29 02:37:24 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF6A106564A for ; Sat, 29 Aug 2009 02:37:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7618FC08 for ; Sat, 29 Aug 2009 02:37:23 +0000 (UTC) Received: by bwz2 with SMTP id 2so1790410bwz.43 for ; Fri, 28 Aug 2009 19:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wKUaQWmLAFs9dH4V0cKeRcp39DQrKTO4bIxRYikp0P4=; b=sNkX4xc9j+QlcQzmY7kN1Myr94nPMrIrfbiEPiQFTboUNk5Nkce/lzp9vsR0mVB66T OdLR5g8hNfm++U8UytEIlW/3s6pp5c2U0xrDEeoaPBY+BK4q+lc8wfpRdko58FB2WNoQ j6R0zOInO3B6fBeG7b9JD3uwdzcIhNw9atgM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=QhhfC8JQV/QRSV1ZGbMR+R60DKw+Uo08azb51/yLdaBDPzlJOqgS0hTkq6r3RkeYh1 lfNF4dJvAF/8hcT44zemzv/YDzdc5xMtYejithoAsXeDiib5a6oDvwvniRClMbqfOQEe xcQ8hDFi+lwkmvI+j+iVWdbi4XfzCsfgfW7DA= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.144.70 with SMTP id y6mr827188fau.12.1251511495714; Fri, 28 Aug 2009 19:04:55 -0700 (PDT) Date: Sat, 29 Aug 2009 04:04:55 +0200 X-Google-Sender-Auth: b7928ec1a477e258 Message-ID: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> From: Attilio Rao To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov Subject: [PATCH] VFS KPI/API versioning 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: Sat, 29 Aug 2009 02:37:24 -0000 Often I found as it would have been useful to verify, mostly at run-time, of a feature of the VFS was supported and I quickly thought that having a run-time check for VFS versioning would not be a bad idea. In order to do that, I made the following patch: http://www.freebsd.org/~attilio/vfs_modload.diff which basically builds the vfs layer as a module adding a version number that can be checked for filesystems/modules willing to load in order to see if a specific feature is supported. Obviously I didn't add an entry in the modules/ neither possibility to unload/shutdown the module because we would not be willing to have such operations (or a run-time load of the vfs). Something that concerned me is also the mis-usage of the VFS_VERSION macro, which can be easilly used at compile time in order to determine if a feature is present or not. Basically, I have no idea by when it doesn't get updated and if it has ever been checked in our codes. It seems to use a random number as the start count, while it could have been handled differently. Maybe it would be the case to start taking care of that too, which can be an interesting tool. Can you comment on the patch? If you think it is a good idea I will commit right away on -CURRENT and STABLE_8. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Aug 29 14:25:10 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with SMTP id 3836B1065674 for ; Sat, 29 Aug 2009 14:25:08 +0000 (UTC) (envelope-from roam@ringlet.net) Received: (qmail 3232 invoked by uid 1000); 29 Aug 2009 14:25:07 -0000 Date: Sat, 29 Aug 2009 17:25:07 +0300 From: Peter Pentchev To: Attilio Rao Message-ID: <20090829142507.GA1141@straylight.m.ringlet.net> References: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konstantin Belousov , freebsd-arch@freebsd.org Subject: Re: [PATCH] VFS KPI/API versioning 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: Sat, 29 Aug 2009 14:25:10 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 29, 2009 at 04:04:55AM +0200, Attilio Rao wrote: [snip] > Something that concerned me is also the mis-usage of the VFS_VERSION > macro, which can be easilly used at compile time in order to determine > if a feature is present or not. Basically, I have no idea by when it > doesn't get updated and if it has ever been checked in our codes. It > seems to use a random number as the start count, while it could have > been handled differently. Maybe it would be the case to start taking > care of that too, which can be an interesting tool. Quite offtopic, just a note about the "random number as the start count" part - it's not exactly random; take a "fgrep 1966" to calendar.freebsd ;) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEUEARECAAYFAkqZOkMACgkQ7Ri2jRYZRVOE2ACYs9roEnhRJRz6HB2x1gb0txtT 0ACfW9oIuc478IO+vU/x2FeU8D3+Hts= =W7Cb -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G--