Date: Sat, 21 Oct 1995 23:01:53 -0700 From: David Greenman <davidg@Root.COM> To: Heikki Suonsivu <hsu@cs.hut.fi> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, stable@freebsd.org Subject: Re: 2.1.0-951020-SNAP - 2.1 *Release Candidate* Message-ID: <199510220601.XAA04220@corbin.Root.COM> In-Reply-To: Your message of "Sun, 22 Oct 95 07:12:29 %2B0200." <199510220512.HAA11965@shadows.cs.hut.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
>Is the slirp panic bug already catched up or still there? I have seen it >PR'd at least two times in addition to my case, and we get regular panics >almost every day on this. I can provide dumps & kernels with full symbols >if someone is interested, it always panics in fchmod and it is quite >consistent. v_mount is NULL, I don't know what circumstances this happens >(it is a pipe or something which isn't on any file system, maybe?). Could >just returning error from the fchmod system call when v_mount is NULL be >enough of a workaround? Sorry that I missed your bug report...you really should trim down your kernel config file - it was so long that I missed the important information at the end of your bug report. :-) Anyway, I've just looked at the problem...it is fixable, but requires an architectural change (one that was made to 4.4BSD-lite/2, but not yet to FreeBSD). Basically, the check for the filesystem being read-only is done at the wrong layer and whenever a filesystem is forcibly dismounted, there is a chance that operations on still-open files will cause this panic. This happens because the filesystem mountpoint has been ripped away. The type/ops vector is also changed to VBAD/deadfs so that future operations on the vnode are directed to the deadfs, but in your case, v_mount is referenced when it obviously shouldn't have been (before it gets to the FS layer). The fix is to move the references to v_mount into the filesystem layer and out of the syscall - this way the fchown (and many other syscalls) will end up in the dead_setattr() (which is defined to return EBADF), before v_mount is ever referenced. ...problem solved. I don't know if I consider this a "critical" bug, however, as it might be difficult to manifest during normal operations. I think that "slirp" must be doing something strange - like an fchown() on a TTY. I'll have to look into this in more detail. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510220601.XAA04220>