From: Liu Bo <bo.li.liu@oracle.com>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] Btrfs: move kobj stuff out of dev_replace lock range
Date: Fri, 17 Jul 2015 19:59:55 +0800 [thread overview]
Message-ID: <20150717115954.GA28169@localhost.localdomain> (raw)
In-Reply-To: <55A8D791.2010402@oracle.com>
On Fri, Jul 17, 2015 at 06:23:13PM +0800, Anand Jain wrote:
>
> On 07/17/2015 04:49 PM, Liu Bo wrote:
> >To avoid deadlock described in commit 084b6e7c7607 ("btrfs: Fix a lockdep warning when running xfstest."),
>
> >we should move kobj stuff out of dev_replace lock range.
>
> Is this just a lock optimizing patch or fixing _a_ cause for the
> deadlock. ? Am I missing something?
The reason that commit 084b6e7c7607 has described[1] matters here, but in my
own case the problem didn't get fixed with this patch, and I'm changing
it into rwlock, which doesn't allow memory allocation inside the lock
range.
Thanks,
-liubo
[1]:
"It is because the btrfs_kobj_{add/rm}_device() will call memory
allocation with GFP_KERNEL,
which may flush fs page cache to free space, waiting for it self to do
the commit, causing the deadlock.
To solve the problem, move btrfs_kobj_{add/rm}_device() out of the
dev_replace lock range, also involing split the
btrfs_rm_dev_replace_srcdev() function into remove and free parts.
Now only btrfs_rm_dev_replace_remove_srcdev() is called in dev_replace
lock range, and kobj_{add/rm} and btrfs_rm_dev_replace_free_srcdev() are
called out of the lock range."
>
> Thanks, Anand
>
>
>
> >Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> >---
> > fs/btrfs/dev-replace.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
> >index 862fbc2..9eb1401 100644
> >--- a/fs/btrfs/dev-replace.c
> >+++ b/fs/btrfs/dev-replace.c
> >@@ -376,10 +376,6 @@ int btrfs_dev_replace_start(struct btrfs_root *root,
> > WARN_ON(!tgt_device);
> > dev_replace->tgtdev = tgt_device;
> >
> >- ret = btrfs_kobj_add_device(tgt_device->fs_devices, tgt_device);
> >- if (ret)
> >- btrfs_error(root->fs_info, ret, "kobj add dev failed");
> >-
> > printk_in_rcu(KERN_INFO
> > "BTRFS: dev_replace from %s (devid %llu) to %s started\n",
> > src_device->missing ? "<missing disk>" :
> >@@ -402,6 +398,10 @@ int btrfs_dev_replace_start(struct btrfs_root *root,
> > args->result = BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_ERROR;
> > btrfs_dev_replace_unlock(dev_replace);
> >
> >+ ret = btrfs_kobj_add_device(tgt_device->fs_devices, tgt_device);
> >+ if (ret)
> >+ btrfs_error(root->fs_info, ret, "kobj add dev failed");
> >+
> > btrfs_wait_ordered_roots(root->fs_info, -1);
> >
> > /* force writing the updated state information to disk */
> >
prev parent reply other threads:[~2015-07-17 12:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 8:49 [PATCH 1/2] Btrfs: move kobj stuff out of dev_replace lock range Liu Bo
2015-07-17 8:49 ` [PATCH 2/2] Btrfs: fix lockdep deadlock warning due to dev_replace Liu Bo
2016-02-04 8:44 ` Qu Wenruo
2016-02-04 14:25 ` David Sterba
2016-02-23 12:28 ` David Sterba
2015-07-17 10:23 ` [PATCH 1/2] Btrfs: move kobj stuff out of dev_replace lock range Anand Jain
2015-07-17 11:59 ` Liu Bo [this message]
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=20150717115954.GA28169@localhost.localdomain \
--to=bo.li.liu@oracle.com \
--cc=anand.jain@oracle.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).