From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/4] btrfs: handle signal interruption during relocation more gracefully
Date: Mon, 13 Jul 2020 09:03:18 +0800 [thread overview]
Message-ID: <20200713010322.18507-1-wqu@suse.com> (raw)
This bug is reported by Hans van Kranenburg <hans@knorrie.org>, that
when a running btrfs balance get fatal signals (including SIGINT), some
bad things can happen, mostly forced RO caused by -EINTR.
It turns out that, although we have addressed the btrfs balance cancel
problems, we haven't addressed the signal related problems.
In theory, processes trapped into kernel space won't get interrupted by
signals, as signal callbacks happen in user space, but kernel code can
still check pending signals and change behavior accordingly.
In this case, the culprit is that, wait_reserve_ticket() can return
-EINTR if there is a pending fatal signal.
While for balance, a lot of situations can't handle the -EINTR from it,
especially for critical cleanup phase.
This patchset will address the bug in two directions:
- Catch fatal signal early
Now btrfs_should_cancel_balance() will also check pending signals.
And will exit gracefully and treat it as a canceled balance.
- Don't allow -EINTR for critical cleanup
For btrfs_drop_snapshot() for reloc trees, we shouldn't be interrupted
by signal, thus we use btrfs_join_transaction() instead of
btrfs_start_transaction().
And for other critical call sites, change the flushing level to avoid
signal interruption.
We also enhance the comment for the btrfs_reserve_flush_enum, to make
it easier to grasp.
Changelog:
v1:
- Change the callers of ticketing system
Still allow certain tickets to be interrupted by signals, and change
the call sites to avoid signal interruption.
v2:
- Add comment for why we can reduce the meta rsv for tree swap
v3:
- Add back the not-yet-merged first patch
- Rephrase the commit message of the 2nd patch
- Add comment for the 3rd patch about the canceled balance return value
- Add a new patch explaining the flushing level
Qu Wenruo (4):
btrfs: relocation: allow signal to cancel balance
btrfs: avoid possible signal interruption for btrfs_drop_snapshot() on
relocation tree
btrfs: relocation: review the call sites which can be interrupted by
signal
btrfs: Add comments for btrfs_reserve_flush_enum
fs/btrfs/ctree.h | 34 ++++++++++++++++++++++++++++++++--
fs/btrfs/extent-tree.c | 5 ++++-
fs/btrfs/relocation.c | 16 +++++++++++++---
fs/btrfs/volumes.c | 14 +++++++++++++-
4 files changed, 62 insertions(+), 7 deletions(-)
--
2.27.0
next reply other threads:[~2020-07-13 1:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 1:03 Qu Wenruo [this message]
2020-07-13 1:03 ` [PATCH v3 1/4] btrfs: relocation: allow signal to cancel balance Qu Wenruo
2020-07-13 1:03 ` [PATCH v3 2/4] btrfs: avoid possible signal interruption for btrfs_drop_snapshot() on relocation tree Qu Wenruo
2020-07-13 1:03 ` [PATCH v3 3/4] btrfs: relocation: review the call sites which can be interrupted by signal Qu Wenruo
2020-07-13 1:03 ` [PATCH v3 4/4] btrfs: Add comments for btrfs_reserve_flush_enum Qu Wenruo
2020-07-15 14:37 ` [PATCH v3 0/4] btrfs: handle signal interruption during relocation more gracefully David Sterba
2020-07-23 21:55 ` Zygo Blaxell
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=20200713010322.18507-1-wqu@suse.com \
--to=wqu@suse.com \
--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).