Date: Sat, 21 Oct 1995 23:01:59 -0700 From: David Greenman <davidg> To: hsu@clinet.fi, davidg, freebsd-bugs Subject: Re: kern/782 Message-ID: <199510220601.XAA26097@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: chmod does a null pointer dereference State-Changed-From-To: open-analyzed State-Changed-By: davidg State-Changed-When: Sat Oct 21 23:00:45 PDT 1995 State-Changed-Why: 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510220601.XAA26097>