From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Bug in OCFS2 umount code
Date: Fri, 24 Oct 2008 15:45:24 -0700 [thread overview]
Message-ID: <20081024224523.GG9302@mail.oracle.com> (raw)
In-Reply-To: <20081024224025.GF9302@mail.oracle.com>
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@oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2008-10-24 22:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 21:57 [Ocfs2-devel] Bug in OCFS2 umount code Jan Kara
2008-10-24 22:40 ` Joel Becker
2008-10-24 22:45 ` Joel Becker [this message]
2008-10-24 22:48 ` Jan Kara
2008-10-25 1:54 ` Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081024224523.GG9302@mail.oracle.com \
--to=joel.becker@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.