linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Josef Bacik <josef@redhat.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: setup blank root and fs_info for mount time
Date: Mon, 22 Nov 2010 09:49:33 +0800	[thread overview]
Message-ID: <1290390573.2602.5.camel@perseus.themaw.net> (raw)
In-Reply-To: <4CE9C677.9050007@cn.fujitsu.com>

On Mon, 2010-11-22 at 09:25 +0800, Li Zefan wrote:
> > +	/*
> > +	 * Setup a dummy root and fs_info for test/set super.  This is because
> > +	 * we don't actually fill this stuff out until open_ctree, but we need
> > +	 * it for searching for existing supers, so this lets us do that and
> > +	 * then open_ctree will properly initialize everything later.
> > +	 */
> > +	fs_info = kzalloc(sizeof(struct btrfs_fs_info), GFP_NOFS);
> > +	tree_root = kzalloc(sizeof(struct btrfs_root), GFP_NOFS);
> > +	if (!fs_info || !tree_root) {
> > +		kfree(fs_info);
> > +		kfree(tree_root);
> 
> The above 2 kfree() calls are redundant.

That's what I thought when I first looked at it but what happens when
fs_info != NULL and tree_root == NULL.

Although I do wonder if doing two successive allocation requests and
then checking both is a good idea. If memory is low there may be a bunch
of page scanning to try and free memory and if it eventually fails that
same process probably would happen all over again on the second call.
I'm not sure though.

> 
> And error should be set to -ENOMEM.

Ah, yes .. I missed that.

> 
> > +		goto error_close_devices;
> > +	}
> > +	fs_info->tree_root = tree_root;
> > +	fs_info->fs_devices = fs_devices;
> > +	tree_root->fs_info = fs_info;
> > +
> >  	bdev = fs_devices->latest_bdev;
> > -	s = sget(fs_type, btrfs_test_super, set_anon_super, fs_devices);
> > +	s = sget(fs_type, btrfs_test_super, btrfs_set_super, tree_root);
> >  	if (IS_ERR(s))
> >  		goto error_s;
> >  
> > @@ -675,6 +702,8 @@ error_s:
> >  	error = PTR_ERR(s);
> >  error_close_devices:
> >  	btrfs_close_devices(fs_devices);
> > +	kfree(fs_info);
> > +	kfree(tree_root);
> >  error_free_subvol_name:
> >  	kfree(subvol_name);
> >  	return ERR_PTR(error);



  reply	other threads:[~2010-11-22  1:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-19 19:59 [PATCH] Btrfs: setup blank root and fs_info for mount time Josef Bacik
2010-11-22  1:25 ` Li Zefan
2010-11-22  1:49   ` Ian Kent [this message]
2010-11-22  1:51     ` Josef Bacik
2010-11-22  2:01     ` Li Zefan
2010-11-22  2:22       ` Ian Kent
2010-11-22  2:21 ` Ian Kent
2010-11-22  9:21   ` Li Zefan
2010-11-22 12:59     ` Ian Kent

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=1290390573.2602.5.camel@perseus.themaw.net \
    --to=raven@themaw.net \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lizf@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).