xfs
[Top] [All Lists]

Re: xfs_cmountfs bug

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: xfs_cmountfs bug
From: Phil Schwan <phil@xxxxxxxxxxxxx>
Date: Wed, 10 May 2000 13:35:45 -0400
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <200005100127.LAA73225@clouds.melbourne.sgi.com>; from Daniel Moore on Wed, May 10, 2000 at 11:27:13AM +1000
References: <200005100127.LAA73225@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
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.

-Phil

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

Attachment: vfsopspatch
Description: Text document

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