From: Dave Chinner <david@fromorbit.com>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Chandra Seetharaman <sekharan@us.ibm.com>, xfsprogs <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfsprogs: fix resouce leak in longform_dir2_rebuild()
Date: Tue, 15 Oct 2013 08:46:01 +1100 [thread overview]
Message-ID: <20131014214601.GJ5663@dastard> (raw)
In-Reply-To: <1381560174.3064.4.camel@ThinkPad-T5421>
On Sat, Oct 12, 2013 at 02:42:54PM +0800, Li Zhong wrote:
> coverity scan 997010 reported following leak in repair/phase6.c
>
> 1309 if (error) {
> 1310 do_warn(
> 1311 _("space reservation failed (%d), filesystem may be out of space\n"),
> 1312 error);
> 25. Breaking from loop
> 1313 break;
> 1314 }
>
> ......
>
> 1342 libxfs_trans_commit(tp,
> 1343 XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_SYNC);
> 1344 }
>
> CID 997010 (#1 of 1): Resource leak (RESOURCE_LEAK)
> 26. leaked_storage: Variable "tp" going out of scope leaks the storage it points to.
> 1345}
>
> Though not reported by coverity, it seems that there might be some entries in
> flist which needs to be freed in the failure case below libxfs_dir_createname(),
> so I also added a bmap cancel there.
>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> ---
> repair/phase6.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/repair/phase6.c b/repair/phase6.c
> index a4ad7a3..0d88ad2 100644
> --- a/repair/phase6.c
> +++ b/repair/phase6.c
> @@ -1310,6 +1310,8 @@ longform_dir2_rebuild(
> do_warn(
> _("space reservation failed (%d), filesystem may be out of space\n"),
> error);
> + libxfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES |
> + XFS_TRANS_ABORT);
As per the rest of the code in phase 6, the error handling here
should call "res_failed()" as we can't sanely recover from an ENOSPC
error during phase6.
> break;
> }
>
> @@ -1323,6 +1325,7 @@ longform_dir2_rebuild(
> do_warn(
> _("name create failed in ino %" PRIu64 " (%d), filesystem may be out of space\n"),
> ino, error);
> + libxfs_bmap_cancel(&flist);
> libxfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES |
> XFS_TRANS_ABORT);
> break;
There's another case exactly the same in that function you missed.
What you should probably do is stack the error handling cases at the
end of the function like:
....
return;
out_bmap_cancel:
libxfs_bmap_cancel(&flist);
out_trans_cancel:
libxfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT);
return;
}
And convert all the error handling cases to jump to the appropriate
error handler.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-10-14 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-12 6:42 [PATCH] xfsprogs: fix resouce leak in longform_dir2_rebuild() Li Zhong
2013-10-14 21:46 ` Dave Chinner [this message]
2013-10-15 2:55 ` [PATCH v2] xfsprogs: fix resource " Li Zhong
2013-10-15 21:39 ` Dave Chinner
2013-10-18 19:33 ` Rich Johnston
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=20131014214601.GJ5663@dastard \
--to=david@fromorbit.com \
--cc=sekharan@us.ibm.com \
--cc=xfs@oss.sgi.com \
--cc=zhong@linux.vnet.ibm.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.