From: Miao Xie <miaox@cn.fujitsu.com>
To: Arne Jansen <lists@die-jansens.de>
Cc: Alex Lyakas <alex.btrfs@zadarastorage.com>,
Jan Schmidt <list.btrfs@jan-o-sch.net>,
Arne Jansen <sensille@gmx.net>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Lev Vainblat <lev@zadarastorage.com>
Subject: Re: Leaking btrfs_qgroup_inherit on snapshot creation?
Date: Thu, 07 Feb 2013 13:10:15 +0800 [thread overview]
Message-ID: <51133737.1020105@cn.fujitsu.com> (raw)
In-Reply-To: <5112491F.3080100@die-jansens.de>
On wed, 06 Feb 2013 13:14:23 +0100, Arne Jansen wrote:
> Hi Alex,
>
> On 02/06/13 12:18, Alex Lyakas wrote:
>> Hi Jan, Arne,
>> I see this code in create_snapshot:
>>
>> if (inherit) {
>> pending_snapshot->inherit = *inherit;
>> *inherit = NULL; /* take responsibility to free it */
>> }
>>
>> So, first thing I think it should be:
>> if (*inherit)
>> because in btrfs_ioctl_snap_create_v2() we have:
>> struct btrfs_qgroup_inherit *inherit = NULL;
>> ...
>> btrfs_ioctl_snap_create_transid(..., &inherit)
>>
>> so the current check is very unlikely to be NULL.
>
> But in btrfs_ioctl_snap_create it is called with NULL, so *inherit would
> dereference a NULL pointer.
>
>>
>> Second, I don't see anybody freeing pending_snapshot->inherit. I guess
>> it should be freed after callin btrfs_qgroup_inherit() and also in
>> btrfs_destroy_pending_snapshots().
>
> You're right. In our original version (6f72c7e20dbaea5) it was still
> there, in transaction.c. It has been removed in 6fa9700e734:
>
> commit 6fa9700e734275de2acbcb0e99414bd7ddfc60f1
> Author: Miao Xie <miaox@cn.fujitsu.com>
> Date: Thu Sep 6 04:00:32 2012 -0600
>
> Btrfs: fix error path in create_pending_snapshot()
>
> This patch fixes the following problem:
> - If we failed to deal with the delayed dir items, we should abort
> transaction,
> just as its comment said. Fix it.
> - If root reference or root back reference insertion failed, we should
> abort transaction. Fix it.
> - Fix the double free problem of pending->inherit.
> - Do not restore the trans->rsv if we doesn't change it.
> - make the error path more clearly.
>
> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
>
> Miao, can you please explain where you see a double free?
Sorry, I misread the code,I didn't notice that the pointer had been assigned
to NULL.
But I think we can make the code more readable and be easy to maintain, we can
free the memory in the caller(btrfs_ioctl_snap_create_v2()) since we are sure
the snapshot creation is done after btrfs_ioctl_snap_create_transid() completes.
Thanks
Miao
prev parent reply other threads:[~2013-02-07 5:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 11:18 Leaking btrfs_qgroup_inherit on snapshot creation? Alex Lyakas
2013-02-06 12:14 ` Arne Jansen
2013-02-07 5:10 ` Miao Xie [this message]
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=51133737.1020105@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=alex.btrfs@zadarastorage.com \
--cc=lev@zadarastorage.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
--cc=lists@die-jansens.de \
--cc=sensille@gmx.net \
/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.