[Ocfs2-devel] Bug in OCFS2 umount code

Joel Becker Joel.Becker at oracle.com
Fri Oct 24 15:45:24 PDT 2008


On Fri, Oct 24, 2008 at 03:40:25PM -0700, Joel Becker wrote:
> On Fri, Oct 24, 2008 at 11:57:02PM +0200, Jan Kara wrote:
> >   while playing with quota support I found two bugs in OCFS2 mount/umount
> > code. The first problem is, that if mount fails, we call
> > ocfs2_dismount_volume(). That is fine but after fill_super() returns an
> > error, VFS calls sync_fs() and ocfs2_put_super() again - not a good idea.
> > We usually oops...
<snip> 
> 	So I don't see a bug in the code as I have it here in my tree.
> I'm going to go check your quota patches to see if perhaps you jump to
> read_super_error after s_root is set.  If so, we can just reorganize
> that.  If not, we'll have to figure out what particular mount failure is
> causing your problem, so we can see what's happening.

	Yeah, you're bailing after setting s_root:

@@ -745,6 +899,13 @@ static int ocfs2_fill_super(struct super_block *sb,
void *data, int silent) 
 
        sb->s_root = root;
 
+       /* Initialize quotas before we start truncation log recovery */
+       status = ocfs2_enable_quotas(osb); 
+       if (status < 0) {
+               mlog_errno(status);
+               goto read_super_error;
+       }

	I don't see why you can't move that above the s_root line.  The
filesystem isn't accessible to userspace yet.  Then your error is safe
to jump to read_super_error.

Joel

-- 

Bram's Law:
	The easier a piece of software is to write, the worse it's
	implemented in practice.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127



More information about the Ocfs2-devel mailing list