From: "Alex Lyakas" <alex@zadarastorage.com>
To: xfs@oss.sgi.com
Subject: xfs_growfs_data_private memory leak
Date: Tue, 1 Jul 2014 18:06:38 +0300 [thread overview]
Message-ID: <4B2A412C75324EE9880358513C069476@alyakaslap> (raw)
In-Reply-To: <20140119231745.GF18112@dastard>
Greetings,
It appears that if xfs_growfs_data_private fails during the "new AG headers"
loop, it does not free all the per-AG structures for the new AGs. When XFS
is unmounted later, they are not freed as well, because
xfs_growfs_data_private did not update the "sb_agcount" field, so
xfs_free_perag will not free them. This happens on 3.8.13, but looking at
the latest master branch, it seems to have the same issue.
Code like [1] in xfs_growfs_data, seems to fix the issue.
A follow-up question: if xfs_grows_data_private fails during the loop that
updates all the secondary superblocks, what is the consequence? (I am aware
that in the latest master branch, the loop is not broken on first error, but
attempts to initialize whatever possible). When these secondary superblocks
will get updated? Is there a way to force-update them? Otherwise, what can
be the consequence of leaving them not updated?
Thanks,
Alex.
[1]
/*
* If we had an error, we might have allocated
* PAGs, which are >=sb_agcount. We need to free
* those, because they will not get freed in
* xfs_free_perag().
*/
if (error) {
unsigned int n_pags = 0;
xfs_perag_t* pags[16] = {0};
xfs_agnumber_t start_agno = mp->m_sb.sb_agcount;
do {
unsigned int pag_idx = 0;
spin_lock(&mp->m_perag_lock);
n_pags = radix_tree_gang_lookup(&mp->m_perag_tree, (void**)pags,
start_agno, ARRAY_SIZE(pags));
for (pag_idx = 0; pag_idx < n_pags; ++pag_idx) {
xfs_perag_t *deleted = NULL;
/* for next lookup */
start_agno = pags[pag_idx]->pag_agno + 1;
/* nobody should really be touching these AGs...*/
if (WARN_ON(atomic_read(&pags[pag_idx]->pag_ref) > 0)) {
pags[pag_idx] = NULL;
continue;
}
deleted = radix_tree_delete(&mp->m_perag_tree,
pags[pag_idx]->pag_agno);
ASSERT(deleted == pags[pag_idx]);
}
spin_unlock(&mp->m_perag_lock);
/* now delete all those still marked for deletion */
for (pag_idx = 0; pag_idx < n_pags; ++pag_idx) {
if (pags[pag_idx])
call_rcu(&pags[pag_idx]->rcu_head,
xfs_free_perag_rcu_cb);
}
} while (n_pags > 0);
}
xfs_free_perag_rcu_cb is similar to __xfs_free_perag, but can be called from
other files.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-07-01 15:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 18:37 Questions about XFS discard and xfs_free_extent() code (newbie) Alex Lyakas
2013-12-18 23:06 ` Dave Chinner
2013-12-19 9:24 ` Alex Lyakas
2013-12-19 10:55 ` Dave Chinner
2013-12-19 19:24 ` Alex Lyakas
2013-12-21 17:03 ` Chris Murphy
2013-12-24 18:21 ` Alex Lyakas
2013-12-26 23:00 ` Dave Chinner
2014-01-08 18:13 ` Alex Lyakas
2014-01-13 3:02 ` Dave Chinner
2014-01-13 17:44 ` Alex Lyakas
2014-01-13 20:43 ` Dave Chinner
2014-01-14 13:48 ` Alex Lyakas
2014-01-15 1:45 ` Dave Chinner
2014-01-19 9:38 ` Alex Lyakas
2014-01-19 23:17 ` Dave Chinner
2014-07-01 15:06 ` Alex Lyakas [this message]
2014-07-01 21:56 ` xfs_growfs_data_private memory leak Dave Chinner
2014-07-02 12:27 ` Alex Lyakas
2014-08-04 18:15 ` Eric Sandeen
2014-08-06 8:56 ` Alex Lyakas
2014-08-04 11:00 ` use-after-free on log replay failure Alex Lyakas
2014-08-04 14:12 ` Brian Foster
2014-08-04 23:07 ` Dave Chinner
2014-08-06 10:05 ` Alex Lyakas
2014-08-06 12:32 ` Dave Chinner
2014-08-06 14:43 ` Alex Lyakas
2014-08-10 16:26 ` Alex Lyakas
2014-08-06 12:52 ` Alex Lyakas
2014-08-06 15:20 ` Brian Foster
2014-08-06 15:28 ` Alex Lyakas
2014-08-10 12:20 ` Alex Lyakas
2014-08-11 13:20 ` Brian Foster
2014-08-11 21:52 ` Dave Chinner
2014-08-12 12:03 ` Brian Foster
2014-08-12 12:39 ` Alex Lyakas
2014-08-12 19:31 ` Brian Foster
2014-08-12 23:56 ` Dave Chinner
2014-08-13 12:59 ` Brian Foster
2014-08-13 20:59 ` Dave Chinner
2014-08-13 23:21 ` Brian Foster
2014-08-14 6:14 ` Dave Chinner
2014-08-14 19:05 ` Brian Foster
2014-08-14 22:27 ` Dave Chinner
2014-08-13 17:07 ` Alex Lyakas
2014-08-13 0:03 ` Dave Chinner
2014-08-13 13:11 ` Brian Foster
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=4B2A412C75324EE9880358513C069476@alyakaslap \
--to=alex@zadarastorage.com \
--cc=xfs@oss.sgi.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