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 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).