From: Nikolay Borisov <nborisov@suse.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, linux-btrfs@vger.kernel.org
Cc: Filipe Manana <fdmanana@suse.com>
Subject: Re: btrfs: sleeping function called from invalid context
Date: Mon, 24 Feb 2020 02:28:22 +0200 [thread overview]
Message-ID: <0c0fa96f-60d6-6a66-3542-d78763bbe269@suse.com> (raw)
In-Reply-To: <20200223234246.GA1208467@mit.edu>
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.
next prev parent reply other threads:[~2020-02-24 0:28 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 [this message]
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
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=0c0fa96f-60d6-6a66-3542-d78763bbe269@suse.com \
--to=nborisov@suse.com \
--cc=fdmanana@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--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.