From owner-freebsd-arch@FreeBSD.ORG Mon Jul 16 10:31:02 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9898D16A405; Mon, 16 Jul 2007 10:31:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1E32D13C481; Mon, 16 Jul 2007 10:31:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6GAUvnQ006407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 20:30:59 +1000 Date: Mon, 16 Jul 2007 20:30:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Sean C. Farley" In-Reply-To: <20070713085330.H21970@thor.farley.org> Message-ID: <20070716202206.G12906@besplex.bde.org> References: <20070711134721.D2385@thor.farley.org> <20070712191616.A4682@delplex.bde.org> <20070712211245.M8625@besplex.bde.org> <20070712142024.Q8789@thor.farley.org> <20070713135453.H8054@delplex.bde.org> <20070713085330.H21970@thor.farley.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: Assembly string functions in i386 libc 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, 16 Jul 2007 10:31:02 -0000 On Fri, 13 Jul 2007, Sean C. Farley wrote: > Actually, the reason I had __pure in main.c was because it exists in > string.h. And I don't have it there since I tested on an old version of FreeBSD. > Using or not using __pure with gcc-3.4.6 has no effect for me even with > the literal argument regardless of optimization (-O0, -O1, or -O2). Not gcc-4.2? gcc-3.4.6 is also for an old (but latest released) version of FreeBSD. Maybe all the __pure's added to actually have an effect only with gcc-4. >> ...[A64 in 32-bit mode similar to AXP] > > BTW, does AXP refer to Athlon XP or Alpha AXP? When I first saw you > write AXP, I thought it was an Alpha. :) It means both, and I think it is in more common use for alpha, but alpha is dead :-). Common use seems to be to spell out "Athlon [tm]", probably for marketing reasons, but the chips are labeled AXP and that is easier to type, so I use it a lot. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jul 16 12:44:54 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07D9B16A40B; Mon, 16 Jul 2007 12:44:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 737C113C4FD; Mon, 16 Jul 2007 12:44:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196927010 for multiple; Mon, 16 Jul 2007 08:36:46 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkK031595; Mon, 16 Jul 2007 08:28:25 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Constantine A. Murenin" Date: Mon, 16 Jul 2007 08:08:04 -0400 User-Agent: KMail/1.9.6 References: <55754.1184143579@critter.freebsd.dk> <200707131252.08792.jhb@freebsd.org> <46985043.8010204@FreeBSD.org> In-Reply-To: <46985043.8010204@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160808.05555.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 16 Jul 2007 08:28:27 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Rui Paulo , Shteryana Shopova , Poul-Henning Kamp , Robert Watson , freebsd-arch@freebsd.org, Alexander Leidinger Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 16 Jul 2007 12:44:54 -0000 On Saturday 14 July 2007 12:25:39 am Constantine A. Murenin wrote: > On 13/07/2007 12:52, John Baldwin wrote: > > > On Friday 13 July 2007 11:48:19 am Constantine A. Murenin wrote: > > > >>On 12/07/2007 14:04, John Baldwin wrote: > >> > >> > >>>On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote: > >>> > >>> > >>>>Quoting John Baldwin (from Wed, 11 Jul 2007 > >>> > >>>11:45:26 -0400): > >>> > >>> > >>>>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote: > >>>> > >>>>>>On the other hand you don't want to allow an userland tool to directly > >>>>>>mess around with the registers on your RAID or NIC to get some status... > >>>>> > >>>>>Err, that's how all the RAID utilities I've used work. They send > > > > firmware > > > >>>>>commands from userland and parse the replies in userland. One exception > >>> > >>>I've > >>> > >>> > >>>>That's sad... they should provide this functionality in the driver > >>>>instead, it would allow to use access restrictions for some parts. > >>> > >>> > >>>Not really, it avoids having to duplicate a lot of work in drivers that > > > > can be > > > >>>written once in a cross-platform userland utility. Drivers aren't really > > > > the > > > >>>place to be monitoring raid status sending pages, e-mails, etc. It's best > > > > to > > > >>>let userland invoke sendmail, not the kernel. :) > >> > >>John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't > >>implement SMTP and don't do emails, they only provide updates to the > >>sensors framework when there are some changes in the state of the drive. :) > >> > >>sensorsd(8) is used to send alerts and emails based on the information > >>from the sensors framework, and user configuration. > >> > >>bioctl(8) is used to configure RAID for _all drivers_. There are no > >>separate utilities for RAID configuration based on brand-name, just like > >>nowadays there are no separate utilities for configuring Ethernet > >>adapters. [0] > > > > > > According to the various manpages on www.openbsd.org you cannot configure > > arrays on the OS for at least mfi(4), ciss(4), twe(4), mpi(4) (like mpt(4) in > > FreeBSD) or ami(4) (like amr(4) in FreeBSD). You can only do monitoring via > > hw.sensors for ciss(4) and ami(4), and the example for monitoring ami(4) in > > the manpage shows that you can only get volume level data, and as a _string_ > > and that you can't get backing physical drive status to know which physical > > drive has failed and needs to be replaced: > > > > $ sysctl hw.sensors.ami0 > > hw.sensors.ami0.drive0=online (sd0), OK > > hw.sensors.ami0.drive1=degraded (sd1), WARNING > > hw.sensors.ami0.drive2=failed (sd2), CRITICAL > > I'm not an expert on RAID monitoring and rebuilding, so I don't think I > can answer your questions about bioctl(8). You might want to refer to a > presentation that was done at BSDCan 2006 by David Gwynne. [b] I've gained some recent experience in a production environment. :) > However, I can tell you that in this sysctl(8) output that you've > quoted, "online" etc and "OK" etc fields are represented as enums (in > sensor datastructure), not strings. I trust that bioctl(8) gives further > status on which exact drive has failed, again, see dlg's presentation. > (Note that the sensors part of that presentation is now a bit outdated.) > > As far as RAID drivers providing sensors are concerned -- a grep for > SENSOR_DRIVE_ONLINE reveals that it is being referenced from ami(4), > arc(4), ciss(4), mfi(4) and softraid(4). From what I could see in the > man pages, mpi(4) chips usually don't provide any raid functionality and > twe(4) lacks programming documentation from the manufacturer, thus > unavailability of RAID sensors from those two drivers doesn't come as a > surprise. ;) Some mpi(4) do provide RAID0 and RAID1. Usually mpi(4) is used as a SAS HBA, but some versions of the chip do support limited RAID. While the mfi(4) driver probably has volume-level data, I doubt it has physical drive-level data as FreeBSD's driver doesn't either. Note that there are 3rd party tools (megarc, MegaCli, the arcmsr (I assume that's arc(4) in openbsd) tool, 3ware's tools) that are available, but they do their work in userland making use of an ioctl to send requests to the firmware. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 17 12:21:41 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AED16A401; Tue, 17 Jul 2007 12:21:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC8B513C471; Tue, 17 Jul 2007 12:21:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E294E48B1F; Tue, 17 Jul 2007 08:21:36 -0400 (EDT) Date: Tue, 17 Jul 2007 13:21:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org, arch@FreeBSD.org Message-ID: <20070717131518.G1177@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 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, 17 Jul 2007 12:21:41 -0000 Dear all: This is a reminder e-mail that, in the very near future, Giant compatibility shims for network protocols will be removed. These shimmed allowed Giant to be re-enabeld over the network stack as a result of linking in a service that required Giant (now all removed), or by setting the debug.mpsafenet variable to 1. This means that the following will no longer be present: debug.mpsafenet sysctl debug_mpsafenet global variable NET_NEEDS_GIANT() NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() NET_CALLOUT_MPSAFE All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they will no be no-ops. The (unused) definition of NET_NEEDS_GIANT() will be removed. The debug.mpsafenet sysctl and debug_mpsafenet global variable will be removed. All instances of NET_CALLOUT_MPSAFE will be converted mechanically to CALLOUT_MPSAFE. The *only* remaining case I am aware of where removing debug.mpsafenet presents an issue is credential-related firewall rules (uid, gid, jail). I'm am currently in an active e-mail discussion with the various firewall maintainers about how to address this issue; as the implementations of these rules violate the global lock order, deadlocks occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a guard lock preventing parallel lock acquisition in the firewall. Hopefully we will have this resolved, in some form, soon. I will remove the above in a series of commits; the only complicated bits are removing the NET_*_GIANT() calls from the socket system call code, where they made things quite a bit more complex than desirable due to additional error handling and unwinding, and in the Cronyx drivers, which interact with debug_mpsafenet in unusual ways (disabling their own locking when Giant is present). Otherwise, this is a fairly low-risk change in practice, since 99% of FreeBSD users have been running without Giant over the network stack since 5.4 (or was it 5.3?). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jul 17 19:53:37 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BDB416A401 for ; Tue, 17 Jul 2007 19:53:37 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by mx1.freebsd.org (Postfix) with ESMTP id BBAFB13C467 for ; Tue, 17 Jul 2007 19:53:36 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1071577ika for ; Tue, 17 Jul 2007 12:53:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=mgxLu0iGumbohmuiEoJj1OyIsvW9NDVNUgtKyDX8IGYcLOlnm+5jWqTANUxouzClef1Ru8SSZrwQVy0xG+4h2GDDOBZvGtnhwVOhsDM7gjX3qeAG4oFeiOs1hVwv+PYJEMDVP2Ckdk5cFrbKVVIU5EYUy/CJGlm8mcSLI/X83cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=IE3i/ufrxKStN37budo+1G5kEGNFpteEvfGc+KEkdfx68LgYfkCSKatIE2EzcyKloKyRZWfPpi5XRVatg3a5s+Ov21bg2imhiBQTmg7NnyMCbxkysEjcgjUVAXrmn8lGkQ2qet+ZVyERIrqt+oOGNNFFqVGDdNv4n9R/9OJ0kfQ= Received: by 10.86.57.9 with SMTP id f9mr534935fga.1184700507464; Tue, 17 Jul 2007 12:28:27 -0700 (PDT) Received: from ?192.168.0.23? ( [79.204.106.93]) by mx.google.com with ESMTPS id e32sm44918fke.2007.07.17.12.28.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Jul 2007 12:28:27 -0700 (PDT) From: Pascal Hofstee To: Robert Watson In-Reply-To: <20070717131518.G1177@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> Content-Type: text/plain Date: Tue, 17 Jul 2007 21:28:26 +0200 Message-Id: <1184700506.1086.5.camel@worf> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 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, 17 Jul 2007 19:53:37 -0000 On Tue, 2007-07-17 at 13:21 +0100, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant compatibility > shims for network protocols will be removed. These shimmed allowed Giant to > be re-enabeld over the network stack as a result of linking in a service that > required Giant (now all removed), or by setting the debug.mpsafenet variable > to 1. This means that the following will no longer be present: > > debug.mpsafenet sysctl > debug_mpsafenet global variable > NET_NEEDS_GIANT() > NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() > NET_CALLOUT_MPSAFE > > All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they will > no be no-ops. Ehrm ... i am not 100% sure here but what will this mean for those of us running qemu on 7.x systems ... if i recall correctly qemu requires aio for at least DMA which on 6.x at least still issues below warning when kldloaded: WARNING: Network stack Giant-free, but aio requires Giant. Consider adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=0 Does this removal of debug.mpsafenet mean that aio on CURRENT is now GIANT free .. or does this mean that we'll be seeing problems with qemu on CURRENT ? -- Pascal Hofstee From owner-freebsd-arch@FreeBSD.ORG Tue Jul 17 20:03:21 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55A0E16A404; Tue, 17 Jul 2007 20:03:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE4E13C4B2; Tue, 17 Jul 2007 20:03:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A67F7470CD; Tue, 17 Jul 2007 16:03:20 -0400 (EDT) Date: Tue, 17 Jul 2007 21:03:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pascal Hofstee In-Reply-To: <1184700506.1086.5.camel@worf> Message-ID: <20070717210053.M1177@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <1184700506.1086.5.camel@worf> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 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, 17 Jul 2007 20:03:21 -0000 On Tue, 17 Jul 2007, Pascal Hofstee wrote: > On Tue, 2007-07-17 at 13:21 +0100, Robert Watson wrote: > >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. These shimmed >> allowed Giant to be re-enabeld over the network stack as a result of >> linking in a service that required Giant (now all removed), or by setting >> the debug.mpsafenet variable to 1. This means that the following will no >> longer be present: >> >> debug.mpsafenet sysctl >> debug_mpsafenet global variable >> NET_NEEDS_GIANT() >> NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT() >> NET_CALLOUT_MPSAFE >> >> All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they >> will no be no-ops. > > Ehrm ... i am not 100% sure here but what will this mean for those of us > running qemu on 7.x systems ... if i recall correctly qemu requires aio for > at least DMA which on 6.x at least still issues below warning when > kldloaded: > > WARNING: Network stack Giant-free, but aio requires Giant. > Consider adding 'options NET_WITH_GIANT' or setting > debug.mpsafenet=0 > > Does this removal of debug.mpsafenet mean that aio on CURRENT is now GIANT > free .. or does this mean that we'll be seeing problems with qemu on CURRENT > ? I believe that davidxu did the work in 7.0 to make aio MPSAFE -- you should not get the above warning with 7.x, only 6.x. The warning is generated by NET_NEEDS_GIANT("aio") in vfs_aio.c, and as of last week, there are no NET_NEEDS_GIANT() callers in 7.x (hence removing the infrastructure for it). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jul 17 21:55:28 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D2C216A400 for ; Tue, 17 Jul 2007 21:55:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id D30CC13C442 for ; Tue, 17 Jul 2007 21:55:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.59.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1IAuok46hu-0004TK; Tue, 17 Jul 2007 23:42:51 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Tue, 17 Jul 2007 23:42:14 +0200 User-Agent: KMail/1.9.7 References: <20070717131518.G1177@fledge.watson.org> In-Reply-To: <20070717131518.G1177@fledge.watson.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1196626.J7k12aMeaH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707172342.39082.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19wTlp8A33NdffBkuSCqDVAD9+nCn7iRlaGezK eaN4BkrpsX6hiwe8m+8VQDx2f86eCa9Ytt2Wkgxy/oHT2itbKU Pk3iYvWGauWY9V9jxacvY/MrZAJ8dPFw1jm9FBMSpQ= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 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, 17 Jul 2007 21:55:28 -0000 --nextPart1196626.J7k12aMeaH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ Excess CC-list ... testers needed!!! ] On Tuesday 17 July 2007, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant > compatibility shims for network protocols will be removed. <...> > The *only* remaining case I am aware of where removing debug.mpsafenet > presents an issue is credential-related firewall rules (uid, gid, > jail). I'm am currently in an active e-mail discussion with the > various firewall maintainers about how to address this issue; as the > implementations of these rules violate the global lock order, deadlocks > occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a > guard lock preventing parallel lock acquisition in the firewall.=20 > Hopefully we will have this resolved, in some form, soon. What we really need right now, is real understanding of the problem (if=20 there even is any). So we would like to ask everybody who is able to -=20 to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw)=20 with debug.mpsafenet=3D1 It is normal that (in an WITNESS enabled kernel)= =20 you get a LOR similar to 14-17 and 32 from [1]. Everything different to=20 those should be reported. If you indeed get a deadlock, please let us know and provide as much=20 debugging information as you can. DDB's "ps", "show locks", "show=20 alllocks" would be perfect, but detailed information how to repeat would=20 be a good start to already. Thanks a lot! If you are unable to provoke a deadlock, please let us know= =20 as well. Include a few setup details (ruleset, SMP, special sysctl=20 settings ...) so we can look for patterns. [1] http://sources.zabbadoz.net/freebsd/lor.html =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1196626.J7k12aMeaH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGnTfPXyyEoT62BG0RAlyQAJ4gRB+txS34yl7wZUd4WEF1fNI32ACfecPR prtWaB/DFI+ykloZIk8nin4= =Mvwf -----END PGP SIGNATURE----- --nextPart1196626.J7k12aMeaH-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 17 22:04:44 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4E4F16A403 for ; Tue, 17 Jul 2007 22:04:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 8511B13C46B for ; Tue, 17 Jul 2007 22:04:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 17 Jul 2007 14:52:06 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 45AB8125AE6; Tue, 17 Jul 2007 14:52:06 -0700 (PDT) Message-ID: <469D3A23.5000809@elischer.org> Date: Tue, 17 Jul 2007 14:52:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Max Laier References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> In-Reply-To: <200707172342.39082.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 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, 17 Jul 2007 22:04:44 -0000 Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, >> jail). I'm am currently in an active e-mail discussion with the >> various firewall maintainers about how to address this issue; as the >> implementations of these rules violate the global lock order, deadlocks >> occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a >> guard lock preventing parallel lock acquisition in the firewall. >> Hopefully we will have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - > to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) > with debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) > you get a LOR similar to 14-17 and 32 from [1]. Everything different to > those should be reported. > > If you indeed get a deadlock, please let us know and provide as much > debugging information as you can. DDB's "ps", "show locks", "show > alllocks" would be perfect, but detailed information how to repeat would > be a good start to already. > > Thanks a lot! If you are unable to provoke a deadlock, please let us know > as well. Include a few setup details (ruleset, SMP, special sysctl > settings ...) so we can look for patterns. I've not seen a deadlock, only LOR warnings. > > [1] http://sources.zabbadoz.net/freebsd/lor.html > From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 10:17:40 2007 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 021DA16A417; Fri, 20 Jul 2007 10:17:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C738C13C458; Fri, 20 Jul 2007 10:17:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 85B3248507; Fri, 20 Jul 2007 06:17:39 -0400 (EDT) Date: Fri, 20 Jul 2007 11:17:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200707172342.39082.max@love2party.net> Message-ID: <20070720111539.U1096@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) 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: Fri, 20 Jul 2007 10:17:40 -0000 On Tue, 17 Jul 2007, Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> This is a reminder e-mail that, in the very near future, Giant >> compatibility shims for network protocols will be removed. > > <...> > >> The *only* remaining case I am aware of where removing debug.mpsafenet >> presents an issue is credential-related firewall rules (uid, gid, jail). >> I'm am currently in an active e-mail discussion with the various firewall >> maintainers about how to address this issue; as the implementations of >> these rules violate the global lock order, deadlocks occur if >> debug.mpsafenet isn't set to 1, which causes Giant to act as a guard lock >> preventing parallel lock acquisition in the firewall. Hopefully we will >> have this resolved, in some form, soon. > > What we really need right now, is real understanding of the problem (if > there even is any). So we would like to ask everybody who is able to - to > stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) with > debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) you get a > LOR similar to 14-17 and 32 from [1]. Everything different to those should > be reported. So far I have had 0 (zero) reports of problems since this thread began. Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try running their firewalls without debug.mpsafenet -- ignore the witness warnings and/or disable witness, and let us know if you experience deadlocks. We're reaching the very end of the merge cycle for 7.0, and I would really like to remove the Giant crutches (now effectively unused) from the network stack so it's not part of the ABI/API, the code is simplified and cleaned up, etc. We'll need to figure out the best way to suppress these witness warnings without suppressing too many other things still. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 18:36:18 2007 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 71AC016A469 for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBE013C478 for ; Fri, 20 Jul 2007 18:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Jul 2007 11:36:17 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 429B2125A23; Fri, 20 Jul 2007 11:36:17 -0700 (PDT) Message-ID: <46A100C2.1030606@elischer.org> Date: Fri, 20 Jul 2007 11:36:50 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Robert Watson References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> In-Reply-To: <20070720111539.U1096@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) 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: Fri, 20 Jul 2007 18:36:18 -0000 Robert Watson wrote: > > On Tue, 17 Jul 2007, Max Laier wrote: > > So far I have had 0 (zero) reports of problems since this thread began. > Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > try running their firewalls without debug.mpsafenet -- ignore the > witness warnings and/or disable witness, and let us know if you > experience deadlocks. We're reaching the very end of the merge cycle > for 7.0, and I would really like to remove the Giant crutches (now > effectively unused) from the network stack so it's not part of the > ABI/API, the code is simplified and cleaned up, etc. > does "problem" include a LOR message, or only a deadlock? I've seen plenty of the first, but not the second. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 19:35:05 2007 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 34C9916A417; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0B21413C457; Fri, 20 Jul 2007 19:35:05 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 04D80E8AC; Fri, 20 Jul 2007 12:12:01 -0700 (PDT) Date: Fri, 20 Jul 2007 12:12:01 -0700 From: Paul Allen To: Julian Elischer Message-ID: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A100C2.1030606@elischer.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) 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: Fri, 20 Jul 2007 19:35:05 -0000 >From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: > Robert Watson wrote: > > > >On Tue, 17 Jul 2007, Max Laier wrote: > > > >So far I have had 0 (zero) reports of problems since this thread began. > >Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > >try running their firewalls without debug.mpsafenet -- ignore the > >witness warnings and/or disable witness, and let us know if you > >experience deadlocks. We're reaching the very end of the merge cycle > >for 7.0, and I would really like to remove the Giant crutches (now > >effectively unused) from the network stack so it's not part of the > >ABI/API, the code is simplified and cleaned up, etc. Wasn't there a a clear solution to the uid/gid problem involving flip-pages: eliminate the pf lock by forcing reconfigurations to build a parallel data-structure and then perform an atomic operation to exchange the pointers. AFAIK, Max's patch was just an ugly hack and it isn't really suitable for performance reasons. What's the state of MAC for the networking stack? Are we able to restrict particular uid's to listening only on particular ports? From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 20:29:24 2007 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 94B0C16A417; Fri, 20 Jul 2007 20:29:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E003013C45A; Fri, 20 Jul 2007 20:29:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9528346B95; Fri, 20 Jul 2007 16:29:22 -0400 (EDT) Date: Fri, 20 Jul 2007 21:29:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> Message-ID: <20070720212206.J83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> <20070720191201.GE5504@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) 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: Fri, 20 Jul 2007 20:29:24 -0000 On Fri, 20 Jul 2007, Paul Allen wrote: > From Julian Elischer , Fri, Jul 20, 2007 at 11:36:50AM -0700: >> Robert Watson wrote: >>> On Tue, 17 Jul 2007, Max Laier wrote: >>> >>> So far I have had 0 (zero) reports of problems since this thread began. >>> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >>> running their firewalls without debug.mpsafenet -- ignore the witness >>> warnings and/or disable witness, and let us know if you experience >>> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >>> would really like to remove the Giant crutches (now effectively unused) >>> from the network stack so it's not part of the ABI/API, the code is >>> simplified and cleaned up, etc. > > Wasn't there a a clear solution to the uid/gid problem involving flip-pages: > eliminate the pf lock by forcing reconfigurations to build a parallel > data-structure and then perform an atomic operation to exchange the > pointers. I think there are a few potential solutions and areas for work here, the trick is figuring out the best approach to get 7.0 out the door. I think any long term structural changes to the firewalls should be avoided at this point, and targeted at 7.1 or 8.0. FYI, my feeling is that the current approach taken, using a pcb lookup in the firewall, is not really an appropriate solution to the problem. Among other things, there are (small) race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. The lock order reversal warning is a symptom of reaching across layers in fairly ugly (and atomicity-unsafe) ways. One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. > AFAIK, Max's patch was just an ugly hack and it isn't really suitable for > performance reasons. > > What's the state of MAC for the networking stack? Are we able to restrict > particular uid's to listening only on particular ports? See mac_portacl(4), which is a functional but not particularly elegant implementation of this idea. In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. The MAC Framework will not be enabled by default in 7.0, but one of my goals for 8.0 is to ship the framework enabled in GENERIC by default. This will require a significant amount of performance optimization to do. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri Jul 20 20:33:42 2007 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 4A51516A419; Fri, 20 Jul 2007 20:33:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F359A13C467; Fri, 20 Jul 2007 20:33:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 902AE48748; Fri, 20 Jul 2007 16:33:40 -0400 (EDT) Date: Fri, 20 Jul 2007 21:33:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <46A100C2.1030606@elischer.org> Message-ID: <20070720213241.N83919@fledge.watson.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) 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: Fri, 20 Jul 2007 20:33:42 -0000 On Fri, 20 Jul 2007, Julian Elischer wrote: > Robert Watson wrote: >> >> On Tue, 17 Jul 2007, Max Laier wrote: >> >> So far I have had 0 (zero) reports of problems since this thread began. >> Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try >> running their firewalls without debug.mpsafenet -- ignore the witness >> warnings and/or disable witness, and let us know if you experience >> deadlocks. We're reaching the very end of the merge cycle for 7.0, and I >> would really like to remove the Giant crutches (now effectively unused) >> from the network stack so it's not part of the ABI/API, the code is >> simplified and cleaned up, etc. > > does "problem" include a LOR message, or only a deadlock? I've seen plenty > of the first, but not the second. Deadlocks. The LOR is expected, but actually a false positive with respect to deadlock potential, we now believe. To be specific: there is a cycle, but since the cycling conditions always involve read acquisition, they shouldn't lead to a wait cycle. So what we're looking for here is evidence of something more than the WITNESS warning. Robert N M Watson Computer Laboratory University of Cambridge