public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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