Date: Sun, 16 Jul 1995 07:27:53 -0700 From: David Greenman <davidg@Root.COM> To: terry@cs.weber.edu (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: Patches for minor MFS bug + discussion Message-ID: <199507161427.HAA03043@corbin.Root.COM> In-Reply-To: Your message of "Sat, 15 Jul 95 19:51:57 MDT." <9507160151.AA08444@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507161427.HAA03043>