kern/142728: Panic: Fatal trap 12 in g_io_request

[Bruce Evans]

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