From: Josef Bacik <jbacik@fusionio.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Chris L. Mason" <clmason@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>
Subject: Re: [patch] Btrfs: dereferencing free'd memory in panic message
Date: Fri, 22 Jun 2012 13:09:04 +0000 [thread overview]
Message-ID: <4FE46E70.8070702@fusionio.com> (raw)
In-Reply-To: <20120622071433.GA27618@elgon.mountain>
On 06/22/2012 03:14 AM, Dan Carpenter wrote:
> We free "node" and then dereference it in the panic message on the next
> line. I considered moving the kfree() after the panic given that panic
> can return under certain configurations, but in the end I decided it
> doesn't matter if we leak a bit after a panic.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 790f492..c50d80a 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -1239,7 +1239,6 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
> node->bytenr, &node->rb_node);
> spin_unlock(&rc->reloc_root_tree.lock);
> if (rb_node) {
> - kfree(node);
> btrfs_panic(root->fs_info, -EEXIST, "Duplicate root found "
> "for start=%llu while inserting into relocation "
> "tree\n", node->bytenr);
Except btrfs_panic can not panic the box if it's mounted to not panic on
errors, so we still need to do the kfree afterwards. Thanks,
Josef
WARNING: multiple messages have this Message-ID (diff)
From: Josef Bacik <jbacik@fusionio.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Chris L. Mason" <clmason@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>
Subject: Re: [patch] Btrfs: dereferencing free'd memory in panic message
Date: Fri, 22 Jun 2012 09:09:04 -0400 [thread overview]
Message-ID: <4FE46E70.8070702@fusionio.com> (raw)
In-Reply-To: <20120622071433.GA27618@elgon.mountain>
On 06/22/2012 03:14 AM, Dan Carpenter wrote:
> We free "node" and then dereference it in the panic message on the next
> line. I considered moving the kfree() after the panic given that panic
> can return under certain configurations, but in the end I decided it
> doesn't matter if we leak a bit after a panic.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 790f492..c50d80a 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -1239,7 +1239,6 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
> node->bytenr, &node->rb_node);
> spin_unlock(&rc->reloc_root_tree.lock);
> if (rb_node) {
> - kfree(node);
> btrfs_panic(root->fs_info, -EEXIST, "Duplicate root found "
> "for start=%llu while inserting into relocation "
> "tree\n", node->bytenr);
Except btrfs_panic can not panic the box if it's mounted to not panic on
errors, so we still need to do the kfree afterwards. Thanks,
Josef
next prev parent reply other threads:[~2012-06-22 13:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 7:14 [patch] Btrfs: dereferencing free'd memory in panic message Dan Carpenter
2012-06-22 7:14 ` Dan Carpenter
2012-06-22 13:09 ` Josef Bacik [this message]
2012-06-22 13:09 ` Josef Bacik
2012-06-22 13:30 ` Dan Carpenter
2012-06-22 13:30 ` Dan Carpenter
2012-06-22 13:32 ` Josef Bacik
2012-06-22 13:32 ` Josef Bacik
2012-06-25 11:15 ` [patch v2] Btrfs: fix error handling in __add_reloc_root() Dan Carpenter
2012-06-25 11:15 ` Dan Carpenter
2012-06-25 13:41 ` Josef Bacik
2012-06-25 13:41 ` Josef Bacik
2012-06-25 13:53 ` Dan Carpenter
2012-06-25 13:53 ` Dan Carpenter
2012-06-26 1:21 ` santosh prasad nayak
2012-06-26 1:33 ` santosh prasad nayak
2012-06-26 6:41 ` Dan Carpenter
2012-06-26 6:41 ` Dan Carpenter
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=4FE46E70.8070702@fusionio.com \
--to=jbacik@fusionio.com \
--cc=clmason@fusionio.com \
--cc=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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.