All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: "Михаил Гаврилов" <mikhail.v.gavrilov@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: task btrfs-cleaner:770 blocked for more than 120 seconds.
Date: Thu, 11 Feb 2016 19:22:27 -0800	[thread overview]
Message-ID: <20160212032226.GA10542@localhost.localdomain> (raw)
In-Reply-To: <CABXGCsPN3MOLkU68gpw=TsnZLODEkYZ66ZHgUxMyeqbdNME9Sw@mail.gmail.com>

On Fri, Feb 12, 2016 at 02:03:15AM +0500, Михаил Гаврилов wrote:
> Thanks guys, I appreciate your's work.
> In which kernel this patch would landed?

You can try it on your 4.2.3 kernel or the latest 4.5, but I guess it
doesn't not fix the real deadlock you're hitting...

Thanks,

-liubo

> 
> --
> Best Regards,
> Mike Gavrilov.
> 
> 
> 2016-02-12 0:18 GMT+05:00 Liu Bo <bo.li.liu@oracle.com>:
> >
> > 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);
> >
> >

  reply	other threads:[~2016-02-12  3:22 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
2016-02-11 21:03               ` Михаил Гаврилов
2016-02-12  3:22                 ` Liu Bo [this message]
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=20160212032226.GA10542@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.