xfs
[Top] [All Lists]

Re: xfs_cmountfs bug

To: cattelan@xxxxxxxxxxx (Russell Cattelan)
Subject: Re: xfs_cmountfs bug
From: Ted Kline <jtk@xxxxxxx>
Date: Wed, 10 May 2000 15:40:15 -0500 (CDT)
Cc: phil@xxxxxxxxxxxxx (Phil Schwan), dxm@xxxxxxxxxxxxxxxxxxxxxxxx (Daniel Moore), linux-xfs@xxxxxxxxxxx
In-reply-to: <3919A199.BE4F151@thebarn.com> from "Russell Cattelan" at May 10, 2000 12:51:21 PM
Sender: owner-linux-xfs@xxxxxxxxxxx
> 
> 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

<Prev in Thread] Current Thread [Next in Thread>