xfs
[Top] [All Lists]

Re: xfs_cmountfs bug

To: Phil Schwan <phil@xxxxxxxxxxxxx>
Subject: Re: xfs_cmountfs bug
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Wed, 10 May 2000 12:51:21 -0500
Cc: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <200005100127.LAA73225@clouds.melbourne.sgi.com> <20000510133544.A13139@linuxcare.com>
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.


>
>
> -Phil
>
> --
> Phil Schwan, Captain Popetastic, Linuxcare Canada
>
>   ------------------------------------------------------------------------
>
>    vfsopspatchName: vfsopspatch
>               Type: Plain Text (text/plain)


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