From: Liu Bo <bo.li.liu@oracle.com>
To: "Михаил Гаврилов" <mikhail.v.gavrilov@gmail.com>,
"Chris Murphy" <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: task btrfs-cleaner:770 blocked for more than 120 seconds.
Date: Thu, 11 Feb 2016 11:18:30 -0800 [thread overview]
Message-ID: <20160211191741.GA4762@localhost.localdomain> (raw)
In-Reply-To: <CAJCQCtTrcnwvumgt-bOx+9wX+f50S9ja5rDrnYAsuuN1aDTsZA@mail.gmail.com>
On Wed, Feb 10, 2016 at 02:23:00PM -0700, Chris Murphy wrote:
> On Wed, Feb 10, 2016 at 1:39 PM, Михаил Гаврилов
> <mikhail.v.gavrilov@gmail.com> wrote:
>
>
> >
> > Here full log: http://btrfs.sy24.ru/kernel-sysrqw-btrfscleaner770blocked-2.txt
> >
> > I am so sorry if this log is useless.
>
> Looks good to me. The blocked task happens out of no where with
> nothing reported for almost an hour before the blocking. And I see the
> sysrq: SysRq : Show Blocked State was issued and lots of information
> is in the file.
>
> > If "sysrq" is needed enabled before hang then I need set this
> > permanently because as I said I not having exactly reproducing this.
>
> echo 1 > /proc/sys/kernel/sysrq can happen anytime, it just enables
> sysrq triggering functions which on Fedora kernels is not enabled by
> default. The main thing is that the echo w to the sysrq trigger needs
> to happen at the time of the problem to show the state. You did that.
> Let's see what Liu Bo has to say about it.
Really appreciate for collecting these, it should be helpful.
Unfortunately I still could not figure out who's holding fs tree's root WRITE_LOCK so that others are blocked.
A possible bug in log code (the follwing patch addressed it),
- log_new_dir_dentries() is holding log tree's leaf READ_LOCK and may try
to get fs tree's READ_LOCK via btrfs_iget() -> btrfs_lookup().
(This is shown in the backtrac)
- btrfs_log_inode() can call btrfs_search_forward() to get fs tree's
leaf READ_LOCK and then call copy_items() -> btrfs_insert_empty_items()
to acquire WRITE_LOCK of log tree's leaf and leaf's parent.
(In the backtrace, this is blocked by item 1 because log_new_dir_dentries is
holding a log tree leaf's READ_LOCK() which happens to be sibling to
the leaf that btrfs_insert_empty_items() is accessing, when doing
split_leaf() it needs to get the sibling's WRITE_LOCK(). )
Thanks,
-liubo
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 323e12c..4a64fdd 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4956,6 +4956,7 @@ process_leaf:
if (di_key.type == BTRFS_ROOT_ITEM_KEY)
continue;
+ btrfs_release_path(path);
di_inode = btrfs_iget(root->fs_info->sb, &di_key,
root, NULL);
if (IS_ERR(di_inode)) {
@@ -4971,7 +4972,6 @@ process_leaf:
ctx->log_new_dentries = false;
if (type == BTRFS_FT_DIR)
log_mode = LOG_INODE_ALL;
- btrfs_release_path(path);
ret = btrfs_log_inode(trans, root, di_inode,
log_mode, 0, LLONG_MAX, ctx);
iput(di_inode);
next prev parent reply other threads:[~2016-02-11 19:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 20:20 task btrfs-cleaner:770 blocked for more than 120 seconds Михаил Гаврилов
2016-02-03 0:41 ` Liu Bo
2016-02-03 2:45 ` Chris Murphy
[not found] ` <CABXGCsOAyYa96E965ruKp9evCY3FrCdBr-GTPvCws5VqmjUC5Q@mail.gmail.com>
2016-02-03 4:37 ` Chris Murphy
2016-02-03 4:48 ` Chris Murphy
2016-02-10 20:39 ` Михаил Гаврилов
2016-02-10 21:23 ` Chris Murphy
2016-02-11 19:18 ` Liu Bo [this message]
2016-02-11 21:03 ` Михаил Гаврилов
2016-02-12 3:22 ` Liu Bo
2016-02-12 3:38 ` Chris Murphy
2016-02-12 20:35 ` Liu Bo
2016-02-12 19:15 ` Михаил Гаврилов
2016-02-12 20:34 ` Liu Bo
2016-02-13 19:23 ` Михаил Гаврилов
2016-02-14 21:32 ` Liu Bo
2016-02-14 22:42 ` Roman Mamedov
2016-02-18 12:35 ` Christian Rohmann
2016-02-18 16:59 ` Liu Bo
2016-02-19 16:00 ` Christian Rohmann
2016-02-19 16:42 ` Chris Murphy
[not found] ` <CABXGCsOVeEBn9A=Wj6VtAEsban6LKj6B958gN8JqK9omLjDt9A@mail.gmail.com>
2016-03-16 9:01 ` Roman Mamedov
2016-03-16 19:54 ` Михаил Гаврилов
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=20160211191741.GA4762@localhost.localdomain \
--to=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=mikhail.v.gavrilov@gmail.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 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.