From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org, Filipe Manana <fdmanana@suse.com>
Subject: Re: btrfs: sleeping function called from invalid context
Date: Mon, 24 Feb 2020 01:46:05 -0500 [thread overview]
Message-ID: <20200224064605.GA1258811@mit.edu> (raw)
In-Reply-To: <0c0fa96f-60d6-6a66-3542-d78763bbe269@suse.com>
On Mon, Feb 24, 2020 at 02:28:22AM +0200, Nikolay Borisov wrote:
> 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.
Hmm... I don't know if the problem has been *completely* fixed, but I
can say that with -rc3 (which has the "fix deadlock during fast fsync
when..." commit), I'm no longer seeing the kernel complaints when I
run "gce-xfstests -c btrfs -g auto". Here are the test results:
TESTRUNID: tytso-20200223230308
KERNEL: kernel 5.6.0-rc3-xfstests #1522 SMP Sun Feb 23 23:01:10 EST 2020 x86_64
CMDLINE: -c btrfs -g auto
CPUS: 2
MEM: 7680
btrfs/default: 988 tests, 8 failures, 203 skipped, 8739 seconds
Failures: btrfs/056 btrfs/153 btrfs/204 generic/065 generic/260
generic/475 generic/562 shared/298
Totals: 785 tests, 203 skipped, 8 failures, 0 errors, 8678s
FSTESTIMG: gce-xfstests/xfstests-202002211357
FSTESTPRJ: gce-xfstests
FSTESTVER: blktests f7b47c5 (Tue, 11 Feb 2020 14:22:21 -0800)
FSTESTVER: e2fsprogs v1.45.4-15-g4b4f7b35 (Wed, 9 Oct 2019 20:25:01 -0400)
FSTESTVER: fio fio-3.18 (Wed, 5 Feb 2020 07:59:58 -0700)
FSTESTVER: fsverity v1.0 (Wed, 6 Nov 2019 10:35:02 -0800)
FSTESTVER: ima-evm-utils v1.2 (Fri, 26 Jul 2019 07:42:17 -0400)
FSTESTVER: nvme-cli v1.10.1 (Tue, 7 Jan 2020 13:55:21 -0700)
FSTESTVER: quota 9a001cc (Tue, 5 Nov 2019 16:12:59 +0100)
FSTESTVER: util-linux v2.35 (Tue, 21 Jan 2020 11:15:21 +0100)
FSTESTVER: xfsprogs v5.4.0 (Fri, 20 Dec 2019 16:47:12 -0500)
FSTESTVER: xfstests-bld a7ae9ff (Tue, 18 Feb 2020 14:22:36 -0500)
FSTESTVER: xfstests linux-v3.8-2692-g3fe2fd0d (Fri, 21 Feb 2020 13:42:43 -0500)
FSTESTCFG: btrfs
FSTESTSET: -g auto
FSTESTOPT: aex
GCE ID: 9110223165715314154
If you want the full test artifacts for this run, in case you want to
dig into the test failures, let me know; I'm happy to send them. The
compressed tarfile is is 1952k, so it's a bit too large for the vger
mailing list.
Cheers,
- Ted
next prev parent reply other threads:[~2020-02-24 6:46 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 [this message]
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=20200224064605.GA1258811@mit.edu \
--to=tytso@mit.edu \
--cc=fdmanana@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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