kern/142728: Panic: Fatal trap 12 in g_io_request

[Henry Wong]

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 at lumeta.com_
732.357.3534 (office)
732.564.0731 (fax)
220 Davidson Avenue
Somerset , NJ 08873-4146
www.lumeta.com