All of lore.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 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.