From owner-freebsd-bugs@FreeBSD.ORG Wed Jan 20 08:14:40 2010 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DCC106566C for ; Wed, 20 Jan 2010 08:14:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3171E8FC15 for ; Wed, 20 Jan 2010 08:14:39 +0000 (UTC) Received: from besplex.bde.org (c220-239-227-214.carlnfd1.nsw.optusnet.com.au [220.239.227.214]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0K8Eaag005594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 19:14:37 +1100 Date: Wed, 20 Jan 2010 19:14:36 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Henry Wong In-Reply-To: <4B560FD7.7050500@lumeta.com> Message-ID: <20100120182631.S1919@besplex.bde.org> References: <201001120250.o0C2o2sI055242@freefall.freebsd.org> <4B4CCBCE.8040004@lumeta.com> <4B4D3DA3.1010706@lumeta.com> <4B560FD7.7050500@lumeta.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/142728: Panic: Fatal trap 12 in g_io_request X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 08:14:40 -0000 On Tue, 19 Jan 2010, Henry Wong wrote: > I have been able to narrow down this problem and have developed and > partially tested a circumvention. The circumvention appears to be > working. > > I found that there was a race condition that allowed a file system to > possibly be mounted read-only more than once. With a certain sequence > of mounting, mounting, retrieving, umounting and retrieving something > different I was able to reproduce the problem. > > This problem can be considered as resolved as a duplicate of the problem > Steve Hartland reported in April of 2008 in the freebsd-stable list: > > 7.0 panic in geom/ufs > 7.0-RELEASE panic any ideas? > > except that it is still occurring in 8.0-RELEASE. There is a PR or 2 about this. Multiple mounts are so broken that they should be considered to be unsupported. Automounting and/or races may make them hard to avoid. > The bottom line is that although FreeBSD 8.0 RELEASE allows a ufs filesystem > to be mounted read-only multiple times, doing so will easily cause the system > to panic trap with either a trap 12 or a trap 9 in g_io_request. > > The instruction that is causing the trap is where it is constructing the > parametes for the g_trace. The particular parameter is pp->name. It > appears that the pp pointer is referring to a page that is not in the > address space. I have no idea whether the *cp from which the pp was > retrieved is valid or not since each time this crashed for me, it either > took no dump or hung after partially dumping. For multiple mounts, unmounting frees storage that is still in use by other mount instance. Eventually, the freed storage is changed or unmapped so something crashes trying to use it. I think mounting does bad things too (apart from not maintaining enough state for unmounting), but usually nothing bad happens because the mount instances are left with different pointers to identical copies of the correct data. Bad things would probably happen for mounting the same device with different logical file systems (this is barely possible using independent implementations of the same physical file systems in the same kernel, or more easily using different physical file systems on the same device). For a quick fix, disallow all multiple mounts like they used to be, even when they are all read-only. While there, please fix the errno's for mount(2): - multiple mounts are still documented to return the correct errno (EBUSY), but they when they are disallowed they now return EPERM (which is only documented to be for a completely different error) - multiple mounts are still documented to return EBUSY (always disallowed). No change is needed after always disallowing them again. - the above EBUSY and several other errors are still only documented for the ffs file system, but most disk file systems have identical error handling. Bruce