From owner-freebsd-hackers  Sun Jul 16 07:27:23 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA26019
          for hackers-outgoing; Sun, 16 Jul 1995 07:27:23 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA26013
          for <hackers@freebsd.org>; Sun, 16 Jul 1995 07:27:20 -0700
Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id HAA14170; Sun, 16 Jul 1995 07:26:43 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id HAA03043; Sun, 16 Jul 1995 07:27:54 -0700
Message-Id: <199507161427.HAA03043@corbin.Root.COM>
To: terry@cs.weber.edu (Terry Lambert)
cc: hackers@freebsd.org
Subject: Re: Patches for minor MFS bug + discussion 
In-reply-to: Your message of "Sat, 15 Jul 95 19:51:57 MDT."
             <9507160151.AA08444@cs.weber.edu> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sun, 16 Jul 1995 07:27:53 -0700
Sender: hackers-owner@freebsd.org
Precedence: bulk

>of the ffs_unmount routine in use here.  This is because the current
>unmount code will probably cause buffer pool corruption on the unmount
>of an MFS file system (if it doesn't cause a panic outright; I'm treating
>free as opaque for the purposes of the discussion).
>
>THE mfs_unmount PATCH IS NOT INCLUDED IN THIS PATCH SET!!!
>
>If one looks in mfs_vfsops.c on line 112 (post-patch), you will see the
>MFS specific data being allocated like so:
>
>	mfsp = malloc(sizeof *mfsp, M_MFSNODE, M_WAITOK);
>
>The equivalent FFS line is in ffs_vfsops.c at line 430:
>
>	ump = malloc(sizeof *ump, M_UFSMNT, M_WAITOK);
>
>The common unmount code (ffs_vfsops.c, line 572) returns either buffer
>to the *UFS* memory pool:
>
>	free(ump, M_UFSMNT);
>
>Clearly, this is broken.

   Clearly? No. The mfsp that is allocated above is assigned to vp->v_data (an
item attached to the vnode) and has nothing to do with the ump that is
assigned to mp->mnt_data (an item in the mount struct). In both FFS and MFS,
a "ump" is allocated in ffs_mountfs(). I think you're getting confused about
the "NODE" that is malloced and later freed in ufs_reclaim(). It figures out
the type depending on the filesystem type; I don't see a bug here.

-DG