From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <linux-btrfs@vger.kernel.org>
Cc: <dsterba@suse.cz>
Subject: [PATCH RFC v2 0/5] Fix bugs introduced by the new pending changes
Date: Tue, 20 Jan 2015 17:05:32 +0800 [thread overview]
Message-ID: <1421744737-16586-1-git-send-email-quwenruo@cn.fujitsu.com> (raw)
Commit 572d9ab7845ea0e0 ("btrfs: add support for processing pending
changes") introduced several bugs which will eventually cause a
deadlock.
The deadlock can be triggered by fstests/generic/068 with inode_cache
mount option.
The deadlock happens in the following flow:
moutn with inode_cache -> freeze fs -> sync -> unfreeze.
Sync_fs stack: Thaw_fs stack:
(Holding s_umount) (Waiting s_umount)
|- btrfs_sync_fs()
|- start_transaction()
(Waiting thaw_fs to unfreeze the fs)
The problem has several causes:
1) Cmpxchg in btrfs_apply_pending_changes() doesn't work
Cmpxchg in btrfs_apply_pending_changes() will only clear
fs_info->pending_changes if it is already 0.
So fs_info->pending_changes will never cleared, and every sync_fs() on
frozen btrfs will try to start a new transaction and deadlock.
So patch 1 fixes it by using xchg() other than cmpxchg().
2) btrfs_freeze() doesn't handle and clear pending_changes
If btrfs start a transaction if there are pending changes but no running
transaction, sync should never start a transaction on frozen fs.
(Except the following sysfs case)
So patch 2~3 fixes it by adding pending changes handler in
btrfs_freeze().
3) Changes through sysfs interface can create pending changes without
waiting for unfreezing.
Since sysfs changes doesn't go through normal open routine,
which will initiate sb_start_*write() and waiting for unfreezing,
changes through sysfs like changing label will set
fs_info->pending_changes to non-zero, and later sync_fs will deadlock
again.
So patch 4~5 reverts the commits relating patches to fix such problem.
Qu Wenruo (5):
btrfs: Fix the bug that fs_info->pending_changes is never cleared.
btrfs: Add btrfs_start_transaction_freeze() to start transaction in
btrfs_freeze()
btrfs: Handle pending changes in btrfs_freeze().
Revert "btrfs: move commit out of sysfs when changing label"
Revert "btrfs: move commit out of sysfs when changing features"
fs/btrfs/super.c | 52 ++++++++++++++++++++++++--------------------------
fs/btrfs/sysfs.c | 34 ++++++++++++++++++++-------------
fs/btrfs/transaction.c | 10 +++++++++-
fs/btrfs/transaction.h | 2 ++
4 files changed, 57 insertions(+), 41 deletions(-)
--
2.2.2
next reply other threads:[~2015-01-20 9:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 9:05 Qu Wenruo [this message]
2015-01-20 9:05 ` [PATCH RFC v2 1/5] btrfs: Fix the bug that fs_info->pending_changes is never cleared Qu Wenruo
2015-01-20 16:01 ` David Sterba
2015-01-20 9:05 ` [PATCH RFC v2 2/5] btrfs: Add btrfs_start_transaction_freeze() to start transaction in btrfs_freeze() Qu Wenruo
2015-01-20 9:05 ` [PATCH RFC v2 3/5] btrfs: Handle pending changes " Qu Wenruo
2015-01-20 9:05 ` [PATCH RFC v2 4/5] Revert "btrfs: move commit out of sysfs when changing label" Qu Wenruo
2015-01-20 9:05 ` [PATCH RFC v2 5/5] Revert "btrfs: move commit out of sysfs when changing features" Qu Wenruo
2015-01-20 15:53 ` [PATCH RFC v2 0/5] Fix bugs introduced by the new pending changes David Sterba
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=1421744737-16586-1-git-send-email-quwenruo@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=dsterba@suse.cz \
--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 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).