From owner-freebsd-stable Sat Oct 21 23:02:31 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26143 for stable-outgoing; Sat, 21 Oct 1995 23:02:31 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA26137 for ; Sat, 21 Oct 1995 23:02:26 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA01822; Sat, 21 Oct 1995 23:02:24 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA04220; Sat, 21 Oct 1995 23:01:54 -0700 Message-Id: <199510220601.XAA04220@corbin.Root.COM> To: Heikki Suonsivu cc: "Jordan K. Hubbard" , stable@freebsd.org Subject: Re: 2.1.0-951020-SNAP - 2.1 *Release Candidate* In-reply-to: Your message of "Sun, 22 Oct 95 07:12:29 +0200." <199510220512.HAA11965@shadows.cs.hut.fi> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 21 Oct 1995 23:01:53 -0700 Sender: owner-stable@freebsd.org Precedence: bulk >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