From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3] Btrfs: fix deadlock with memory reclaim during scrub
Date: Fri, 23 Nov 2018 16:41:45 +0000 [thread overview]
Message-ID: <20181123164145.32027-1-fdmanana@kernel.org> (raw)
In-Reply-To: <20181123134543.20199-1-fdmanana@kernel.org>
From: Filipe Manana <fdmanana@suse.com>
When a transaction commit starts, it attempts to pause scrub and it blocks
until the scrub is paused. So while the transaction is blocked waiting for
scrub to pause, we can not do memory allocation with GFP_KERNEL while scrub
is running, we must use GFP_NOS to avoid deadlock with reclaim. Checking
for pause requests is done early in the while loop of scrub_stripe(), and
later in the loop, scrub_extent() is called, which in turns calls
scrub_pages(), which does memory allocations using GFP_KERNEL. So use
GFP_NOFS for the memory allocations because at any time a scrub pause
request can happen from another task that started to commit a transaction.
Fixes: 58c4e173847a ("btrfs: scrub: use GFP_KERNEL on the submission path")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
V2: Make using GFP_NOFS unconditionial. Previous version was racy, as pausing
requests migth happen just after we checked for them.
V3: Use memalloc_nofs_save() just like V1 did.
fs/btrfs/scrub.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 3be1456b5116..8e9ead5073ec 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2204,13 +2204,24 @@ static int scrub_pages(struct scrub_ctx *sctx, u64 logical, u64 len,
{
struct scrub_block *sblock;
int index;
+ unsigned int nofs_flag;
+ int ret = 0;
+
+ /*
+ * In order to avoid deadlock with reclaim when there is a transaction
+ * trying to pause scrub, use GFP_NOFS. The pausing request is done when
+ * the transaction commit starts, and it blocks the transaction until
+ * scrub is paused (done at specific points at scrub_stripe()).
+ */
+ nofs_flag = memalloc_nofs_save();
sblock = kzalloc(sizeof(*sblock), GFP_KERNEL);
if (!sblock) {
spin_lock(&sctx->stat_lock);
sctx->stat.malloc_errors++;
spin_unlock(&sctx->stat_lock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
/* one ref inside this function, plus one for each page added to
@@ -2230,7 +2241,8 @@ static int scrub_pages(struct scrub_ctx *sctx, u64 logical, u64 len,
sctx->stat.malloc_errors++;
spin_unlock(&sctx->stat_lock);
scrub_block_put(sblock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
BUG_ON(index >= SCRUB_MAX_PAGES_PER_BLOCK);
scrub_page_get(spage);
@@ -2269,12 +2281,11 @@ static int scrub_pages(struct scrub_ctx *sctx, u64 logical, u64 len,
} else {
for (index = 0; index < sblock->page_count; index++) {
struct scrub_page *spage = sblock->pagev[index];
- int ret;
ret = scrub_add_page_to_rd_bio(sctx, spage);
if (ret) {
scrub_block_put(sblock);
- return ret;
+ goto out;
}
}
@@ -2284,7 +2295,9 @@ static int scrub_pages(struct scrub_ctx *sctx, u64 logical, u64 len,
/* last one frees, either here or in bio completion for last page */
scrub_block_put(sblock);
- return 0;
+out:
+ memalloc_nofs_restore(nofs_flag);
+ return ret;
}
static void scrub_bio_end_io(struct bio *bio)
--
2.11.0
next prev parent reply other threads:[~2018-11-23 16:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-23 13:45 [PATCH] Btrfs: fix deadlock with memory reclaim during scrub fdmanana
2018-11-23 16:05 ` [PATCH v2] " fdmanana
2018-11-23 16:13 ` Nikolay Borisov
2018-11-23 16:41 ` fdmanana [this message]
2018-11-23 18:25 ` [PATCH v4] " fdmanana
2018-11-26 7:27 ` Nikolay Borisov
2018-11-26 18:17 ` David Sterba
2018-11-26 20:10 ` Filipe Manana
2018-11-28 14:22 ` David Sterba
2018-11-28 14:40 ` Filipe Manana
2018-12-04 14:47 ` David Sterba
2018-11-26 20:07 ` [PATCH v5] " fdmanana
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=20181123164145.32027-1-fdmanana@kernel.org \
--to=fdmanana@kernel.org \
--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 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.