kern/142728: Panic: Fatal trap 12 in g_io_request
hwong at lumeta.com
Tue Jan 19 20:09:47 UTC 2010
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 wrote:
> I have been able to narrow down this problem and have developed and
> partially tested a circumvention. The circumvention appears to be
> 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
> to be mounted read-only multiple times, doing so will easily cause the
> 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
Lead Software Engineer
Lumeta - / Securing the Network in the Face of Change
_hwong at lumeta.com_
220 Davidson Avenue
Somerset , NJ 08873-4146
More information about the freebsd-bugs