Date: Tue, 19 Jan 2010 15:09:43 -0500 From: Henry Wong <hwong@lumeta.com> To: freebsd-bugs@FreeBSD.org, Henry Wong <hwong@lumeta.com> Subject: Re: kern/142728: Panic: Fatal trap 12 in g_io_request Message-ID: <4B561187.3030308@lumeta.com> In-Reply-To: <4B560FD7.7050500@lumeta.com> References: <201001120250.o0C2o2sI055242@freefall.freebsd.org> <4B4CCBCE.8040004@lumeta.com> <4B4D3DA3.1010706@lumeta.com> <4B560FD7.7050500@lumeta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Clarification: The race condition and the circumvention was in application code running on the machine, not in the FreeBSD kernel. FreeBSD allows a file system to be mounted read-only multiple times. That is not a race condition. Henry Wong 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. > > 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. > > -- > > > Henry Wong > Lead Software Engineer > > Lumeta - / Securing the Network in the Face of Change > / > _hwong@lumeta.com_ > 732.357.3534 (office) > 732.564.0731 (fax) > 220 Davidson Avenue > Somerset , NJ 08873-4146 > www.lumeta.com > -- Henry Wong Lead Software Engineer Lumeta - / Securing the Network in the Face of Change / _hwong@lumeta.com_ 732.357.3534 (office) 732.564.0731 (fax) 220 Davidson Avenue Somerset , NJ 08873-4146 www.lumeta.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B561187.3030308>