From owner-freebsd-current Mon Sep 11 13:32:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA02292 for current-outgoing; Mon, 11 Sep 1995 13:32:15 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA02071 for ; Mon, 11 Sep 1995 13:31:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA20905; Mon, 11 Sep 1995 13:23:16 -0700 From: Terry Lambert Message-Id: <199509112023.NAA20905@phaeton.artisoft.com> Subject: Re: BAD BUG IN UFS RENAME To: davidg@root.com Date: Mon, 11 Sep 1995 13:23:16 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org, mckusick@mckusick.com In-Reply-To: <199509112011.NAA03186@corbin.Root.COM> from "David Greenman" at Sep 11, 95 01:11:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1425 Sender: current-owner@freebsd.org Precedence: bulk > > >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.