>
> Phil Schwan wrote:
>
> > On May 10, Daniel Moore wrote:
> > > Attached is an ugly hack that fixes the problem. I'll leave it up
> > > to someone who knows what's meant to happen to fix it properly.
> > >
> > > (to test: modprobe xfs, lsmod, try to mount a non-mounted, non-xfs
> > > FS as an XFS fs, then lsmod again and check the usage counts - they
> > > should increase for each failed mount)
> > >
> > > dxm@sherman ~/isms/slinx-xfs> p_rdiff linux/fs/xfs/xfs_vfsops.c
> > > 503a504
> > > > ddevvp=(vnode_t*)1; /* XXX DXM hack */
> > > 505a507
> > > > ldevvp=(vnode_t*)1; /* XXX DXM hack */
> > > 508a511
> > > > rdevvp=(vnode_t*)1; /* XXX DXM hack */
> >
> > As far as I can tell, the sole purpose of {dd,ld,rd}evvp is to know
> > whether the inodes need freed in the case of an error. I don't think
> > we need these variables at all. It's impossible to get to that bit of
> > error cleanup code until after the buftargs are filled--thus, we can
> > just free them under the same conditions that we allocated them.
> >
> > I prefer this patch. If there's no objections, I'll commit it
> > tomorrow.
>
> Ted has mad a lot changes to the vnode/ linux inode's
> I might be best to wait until his changes are done
> before we chase the problem to much.
I'm okay with this, am already handling the special linvfs_release_.. case..
-Ted
|