All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs: sleeping function called from invalid context
Date: Mon, 24 Feb 2020 10:11:26 +0000	[thread overview]
Message-ID: <CAL3q7H5s2pZV-KExti7M5+yVG7N7zFVVzGvNdAiZCthMfNSoQg@mail.gmail.com> (raw)
In-Reply-To: <0c0fa96f-60d6-6a66-3542-d78763bbe269@suse.com>

On Mon, Feb 24, 2020 at 12:30 AM Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> On 24.02.20 г. 1:42 ч., Theodore Y. Ts'o wrote:
> > Hi, I noticed this when I was doing some build tests; is this a known issue?
> >
>
> So this is fallout from 28553fa992cb28be6a65566681aac6cafabb4f2d because
> it's being called while we have locked extent buffers (before calling
> btrfs_free_Path which is holding a rwlock (a variant of spinlock). And
> actually unlocking btrfs' extent requires allocating structures to
> reflect the new state. This allocation is currently done with GFP_NOFS
> which implies DIRECT_RECLAIM hence the maybe sleep from slab allocator
> is triggered.
>
> Filipe, can the unlock be done _after_ freeing the path or even better -
> reduce the critical section altogether in btrfs_truncate_inode_items?
>
> I don't think '[PATCH] Btrfs: fix deadlock during fast fsync when
> logging prealloc extents beyond eof' actually fixes the problem since
> the unlock can happen under the path again.

The problem is that that patch was made against the integration branch
(misc-next) where truncate doesn't use btree search paths with
spinning locks anymore, so it didn't trigger that problem during
development.
The patch was then picked into 5.6-rc2, where we still use spinning
locks, whence people reporting the issue (before Ted, Dave Jones and a
few others had reported it as well).

The solution was to pick a patch from the integration branch into 5.6-rc3:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52e29e331070cd7d52a64cbf1b0958212a340e28

That solves the sleep in invalid context warnings.
>


-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

      parent reply	other threads:[~2020-02-24 10:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-23 23:42 btrfs: sleeping function called from invalid context Theodore Y. Ts'o
2020-02-24  0:28 ` Nikolay Borisov
2020-02-24  6:46   ` Theodore Y. Ts'o
2020-02-24 10:14     ` Filipe Manana
2020-02-24 21:56       ` Theodore Y. Ts'o
2020-02-25  9:36         ` Filipe Manana
2020-02-24 10:11   ` Filipe Manana [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=CAL3q7H5s2pZV-KExti7M5+yVG7N7zFVVzGvNdAiZCthMfNSoQg@mail.gmail.com \
    --to=fdmanana@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=tytso@mit.edu \
    /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.