On Mon, Feb 24, 2020 at 6:47 AM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > 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. We do have some tests that fail in any kernel release so far. Some because the corresponding fixes are not yet merged or some fail often due to known problems. Looking at your list of failure, I see some that shouldn't be failing like btrfs/053. If you want you can send me the test logs to my gmail address. Thanks. > > Cheers, > > - Ted -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
