From owner-svn-src-all@freebsd.org Fri Nov 20 07:53:26 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 895B7A33B79; Fri, 20 Nov 2015 07:53:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 48BCF1C07; Fri, 20 Nov 2015 07:53:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id CCCD13C335B; Fri, 20 Nov 2015 18:22:26 +1100 (AEDT) Date: Fri, 20 Nov 2015 18:22:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Jonathan T. Looney" cc: John Baldwin , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r291074 - in head: share/man/man9 sys/kern sys/vm In-Reply-To: Message-ID: <20151120171730.I2071@besplex.bde.org> References: <201511191404.tAJE4reJ064779@repo.freebsd.org> <8452745.P4SYfkWpxv@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R4L+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=Uc_2HgOp98-BiDlb7ikA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 07:53:26 -0000 On Thu, 19 Nov 2015, Jonathan T. Looney wrote: > On 11/19/15, 12:58 PM, "John Baldwin" wrote: >> Note that if you are going to document in each section 9 manpage which >> APIs >> are not safe to call in a critical section, you will need to update just >> about every section 9 manpage. A more prudent approach would probably be >> to >> instead go the sigaction(2) route and instead document the subset of APIs >> which are permissible to call in critical_enter(9). The list is probably >> not >> very long. Off the top of my head I can think of sched_*, swi_sched, >> taskqueue_enqueue_fast, and little else. > > Point taken. Both the man page and the KASSERT()s with redundant (yet incomplete) "or" clause about spinlocks. The change also has some style bugs (extra blank lines). The above list is similar to the list of APIs that may be called by a "fast" interrupt handler. It is much smaller than the full list, but still unmanageably large. The closure of the list is difficult to determined, and the closure of the list of calls actually made is infinite due to bugs like console drivers calling kdb_alt_break() which calls everything via reboot() and panic() (also via kdb_enter(), but the only correct reason for existence of kdb_alt_break() is to enter kdb, and kdb is a little more careful about not calling everything). > As noted above, the point wasn't to enable checking when WITNESS was > disabled; rather, the point was to make the existing checks more > consistent. Basically, if you do something that engenders a panic at high > scale, you should get consistent behavior at low scale, too. Checking that is actually done is also likely to cause recursive panics when panic() is called with in a critical section or in another bad state. This may be considered as a feature. It limits the damage when panic() wanders into normal code does unsafe things for the bad state, and inhibits bugs like kdb_alt_break() calling panic(). Bruce