Date: Mon, 11 Sep 1995 13:23:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@root.com Cc: terry@lambert.org, current@freebsd.org, mckusick@mckusick.com Subject: Re: BAD BUG IN UFS RENAME Message-ID: <199509112023.NAA20905@phaeton.artisoft.com> In-Reply-To: <199509112011.NAA03186@corbin.Root.COM> from "David Greenman" at Sep 11, 95 01:11:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >Well, I've discovered some very interesting brain damage. > > > >In the case of an attemped cross-device rename, both NAMEI buffers are > >freed twice. > > Yes, I think I see this - the VOP_ABORTOP's on both cn buffers, followed by > the explicit free's in rename()? Yes. It's not obvious because they check the HASBUF in the VOP_ABORTOP; the actual rename stuff will work for UFS, assuming that there aren't any cascade errors, but not for other file systems. This because they check that the SAVESTART bit isn't set to determine the free behaviour. So it's not as blatant as it would seem the first time you glance at it; it *will* work except it blows in a couple of error cases and one interaction with the miscfs/union/union_subr.c code. This could very well be the MSDOSFS rename bug. The union stuff fails similarly. SAVESTART is only set in two modules: vfs_syscalls and nfs_serv.c; the first in the rename case, and the second on lookup, create, mknod, rename, and symlink. Actually, nulling out the VOP_ABORTOP free and explicitly freeing the HASBUF buffer (the plan) will fix the problem areas as well as the layering. I'm also planning on a freed flag for the DIAGNOSTIC case to ensure a re-free will fail with a panic(), but this is not a high priority. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509112023.NAA20905>