* btrfs: sleeping function called from invalid context
@ 2020-02-23 23:42 Theodore Y. Ts'o
2020-02-24 0:28 ` Nikolay Borisov
0 siblings, 1 reply; 7+ messages in thread
From: Theodore Y. Ts'o @ 2020-02-23 23:42 UTC (permalink / raw)
To: linux-btrfs
Hi, I noticed this when I was doing some build tests; is this a known issue?
[ 74.030154] BUG: sleeping function called from invalid context at mm/slab.h:565
[ 74.037763] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14425, name: dd
[ 74.046849] 4 locks held by dd/14425:
[ 74.052024] #0: ffff91960e34f498 (sb_writers#14){.+.+}, at: mnt_want_write+0x20/0x50
[ 74.060008] #1: ffff9195fe328708 (&sb->s_type->i_mutex_key#18){+.+.}, at: do_truncate+0x69/0xd0
[ 74.070311] #2: ffff91960e34f6f8 (sb_internal#2){.+.+}, at: start_transaction+0x3cf/0x550
[ 74.078721] #3: ffff919602d6c740 (btrfs-tree-00){++++}, at: btrfs_tree_lock+0x77/0x270
[ 74.088791] CPU: 0 PID: 14425 Comm: dd Not tainted 5.6.0-rc2-xfstests-00009-g9db176bceb5c #1518
[ 74.097618] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 74.106966] Call Trace:
[ 74.110926] dump_stack+0x71/0xa0
[ 74.114369] ___might_sleep.cold+0xa6/0xb6
[ 74.118586] kmem_cache_alloc+0x26f/0x350
[ 74.122724] alloc_extent_state+0x20/0x1a0
[ 74.126989] __clear_extent_bit+0x2f4/0x5c0
[ 74.131290] ? _raw_spin_unlock_irq+0x24/0x30
[ 74.135771] btrfs_truncate_inode_items+0x33e/0xd90
[ 74.140769] ? do_raw_spin_unlock+0x4b/0xc0
[ 74.145076] btrfs_setsize.isra.0+0x203/0x4d0
[ 74.149554] btrfs_setattr+0x5e/0xe0
[ 74.153254] notify_change+0x357/0x4e0
[ 74.157120] do_truncate+0x76/0xd0
[ 74.160654] do_last+0x404/0x860
[ 74.164004] path_openat+0x8f/0x240
[ 74.167617] do_filp_open+0x91/0x100
[ 74.171327] ? do_raw_spin_unlock+0x4b/0xc0
[ 74.175650] ? _raw_spin_unlock+0x1f/0x30
[ 74.179778] do_sys_openat2+0x1fc/0x2a0
[ 74.183742] do_sys_open+0x44/0x80
[ 74.187323] do_syscall_64+0x50/0x1f0
[ 74.192500] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 74.197676] RIP: 0033:0x7fd0d67be1ae
[ 74.201369] Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 59 65 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
[ 74.221644] RSP: 002b:00007fff579e3000 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
[ 74.229331] RAX: ffffffffffffffda RBX: 000055cbdb1853e0 RCX: 00007fd0d67be1ae
[ 74.236586] RDX: 0000000000000241 RSI: 00007fff579e4e2c RDI: 00000000ffffff9c
[ 74.243835] RBP: 0000000000000001 R08: 000055cbdb17f2e6 R09: 0000000000000000
[ 74.251092] R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000241
[ 74.258452] R13: 00007fff579e4e2c R14: 0000000000000001 R15: 00007fff579e32f8
It's causing very large number of xfstests failures:
TESTRUNID: tytso-20200222194637
KERNEL: kernel 5.6.0-rc2-xfstests-00009-g9db176bceb5c #1518 SMP Fri Feb 21 19:32:23 EST 2020 x86_64
CMDLINE: -c btrfs -g auto
CPUS: 2
MEM: 7680
btrfs/default: 988 tests, 300 failures, 203 skipped, 8951 seconds
Failures: btrfs/002 btrfs/004 btrfs/005 btrfs/007 btrfs/013
btrfs/014 btrfs/020 btrfs/022 btrfs/024 btrfs/026 btrfs/028
btrfs/034 btrfs/037 btrfs/041 btrfs/055 btrfs/056 btrfs/057
btrfs/076 btrfs/078 btrfs/080 btrfs/081 btrfs/094 btrfs/095
btrfs/096 btrfs/098 btrfs/108 btrfs/109 btrfs/119 btrfs/137
btrfs/138 btrfs/139 btrfs/153 btrfs/156 btrfs/159 btrfs/169
btrfs/173 btrfs/174 btrfs/177 btrfs/179 btrfs/183 btrfs/188
btrfs/191 btrfs/199 btrfs/200 btrfs/201 btrfs/204 generic/001
generic/005 generic/006 generic/007 generic/008 generic/009
generic/011 generic/013 generic/014 generic/018 generic/027
generic/030 generic/032 generic/033 generic/039 generic/040
generic/041 generic/056 generic/057 generic/062 generic/066
generic/068 generic/070 generic/074 generic/075 generic/076
generic/077 generic/078 generic/079 generic/080 generic/083
generic/086 generic/087 generic/089 generic/090 generic/091
generic/092 generic/093 generic/094 generic/095 generic/096
generic/097 generic/099 generic/101 generic/103 generic/104
generic/105 generic/107 generic/109 generic/110 generic/112
generic/113 generic/114 generic/116 generic/117 generic/118
generic/119 generic/121 generic/122 generic/123 generic/124
generic/126 generic/127 generic/129 generic/130 generic/131
generic/133 generic/134 generic/136 generic/137 generic/138
generic/139 generic/140 generic/142 generic/143 generic/144
generic/146 generic/149 generic/150 generic/151 generic/152
generic/154 generic/155 generic/157 generic/158 generic/159
generic/169 generic/175 generic/176 generic/177 generic/178
generic/179 generic/180 generic/181 generic/182 generic/193
generic/198 generic/199 generic/200 generic/204 generic/209
generic/213 generic/225 generic/239 generic/240 generic/241
generic/245 generic/248 generic/249 generic/254 generic/255
generic/256 generic/257 generic/259 generic/260 generic/263
generic/269 generic/277 generic/285 generic/286 generic/297
generic/298 generic/299 generic/300 generic/301 generic/302
generic/303 generic/304 generic/306 generic/307 generic/308
generic/309 generic/310 generic/311 generic/313 generic/315
generic/316 generic/318 generic/319 generic/320 generic/321
generic/322 generic/324 generic/325 generic/329 generic/336
generic/337 generic/339 generic/342 generic/343 generic/347
generic/348 generic/352 generic/353 generic/356 generic/357
generic/361 generic/375 generic/376 generic/377 generic/389
generic/390 generic/391 generic/393 generic/407 generic/408
generic/409 generic/410 generic/411 generic/414 generic/415
generic/416 generic/418 generic/420 generic/423 generic/426
generic/427 generic/434 generic/436 generic/438 generic/439
generic/444 generic/446 generic/447 generic/448 generic/450
generic/451 generic/454 generic/463 generic/464 generic/465
generic/467 generic/469 generic/472 generic/475 generic/476
generic/477 generic/479 generic/480 generic/481 generic/483
generic/488 generic/489 generic/490 generic/493 generic/494
generic/495 generic/496 generic/498 generic/501 generic/502
generic/509 generic/510 generic/511 generic/512 generic/515
generic/516 generic/520 generic/523 generic/524 generic/526
generic/527 generic/528 generic/531 generic/532 generic/534
generic/535 generic/538 generic/539 generic/541 generic/543
generic/545 generic/546 generic/547 generic/551 generic/552
generic/553 generic/555 generic/557 generic/560 generic/561
generic/562 generic/564 generic/567 generic/569 generic/571
generic/578 generic/585 generic/586 generic/588 generic/589
generic/591 shared/002 shared/298
Totals: 785 tests, 203 skipped, 300 failures, 0 errors, 8909s
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: 8335279961640039838
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: btrfs: sleeping function called from invalid context
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
2020-02-24 10:11 ` Filipe Manana
0 siblings, 2 replies; 7+ messages in thread
From: Nikolay Borisov @ 2020-02-24 0:28 UTC (permalink / raw)
To: Theodore Y. Ts'o, linux-btrfs; +Cc: Filipe Manana
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs: sleeping function called from invalid context
2020-02-24 0:28 ` Nikolay Borisov
@ 2020-02-24 6:46 ` Theodore Y. Ts'o
2020-02-24 10:14 ` Filipe Manana
2020-02-24 10:11 ` Filipe Manana
1 sibling, 1 reply; 7+ messages in thread
From: Theodore Y. Ts'o @ 2020-02-24 6:46 UTC (permalink / raw)
To: Nikolay Borisov; +Cc: linux-btrfs, Filipe Manana
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: btrfs: sleeping function called from invalid context
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
0 siblings, 1 reply; 7+ messages in thread
From: Filipe Manana @ 2020-02-24 10:14 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: Nikolay Borisov, linux-btrfs
On Mon, Feb 24, 2020 at 6:47 AM Theodore Y. Ts'o <tytso@mit.edu> 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.”
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs: sleeping function called from invalid context
2020-02-24 10:14 ` Filipe Manana
@ 2020-02-24 21:56 ` Theodore Y. Ts'o
2020-02-25 9:36 ` Filipe Manana
0 siblings, 1 reply; 7+ messages in thread
From: Theodore Y. Ts'o @ 2020-02-24 21:56 UTC (permalink / raw)
To: Filipe Manana; +Cc: Nikolay Borisov, linux-btrfs
On Mon, Feb 24, 2020 at 10:14:06AM +0000, Filipe Manana wrote:
> 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.
I've sent you the compressed tarfile with the test artifacts under
separate cover. The files that you'll probably want to look at first
are ./runtests.log and ./syslog. The xfstests results artifacts will
be in ./btrfs/results-default/.
If you have a wiki page or some other pointer of what tests that you
expect to fail, I can put them into a btrfs-specific or file system
configuration specific exclude file. For example, see [1] and [2].
[1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/exclude
[2] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/cfg/bigalloc.exclude
I'm planning on running btrfs and xfs tests more frequently to support
some $WORK initiatives. So if there are tests which are known
failures that would be good for me to suppress, and if there are some
file system configurations that would be useful for me to run, please
let me know and I'm happy to set them so that gce-xfstests and
kvm-xfstests can better test btrfs.
Also, I assume you do have some btrfs developers who are regularly
running xfstests, so I don't know how helpful this would be to you,
but given that I'm going to be running the tests *anyway*, if it would
be helpful for me to forward test results to you, or to only send you
a note when test regressions show up, I'm happy to do that.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs: sleeping function called from invalid context
2020-02-24 21:56 ` Theodore Y. Ts'o
@ 2020-02-25 9:36 ` Filipe Manana
0 siblings, 0 replies; 7+ messages in thread
From: Filipe Manana @ 2020-02-25 9:36 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: Nikolay Borisov, linux-btrfs
On Mon, Feb 24, 2020 at 9:56 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Mon, Feb 24, 2020 at 10:14:06AM +0000, Filipe Manana wrote:
> > 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.
>
> I've sent you the compressed tarfile with the test artifacts under
> separate cover. The files that you'll probably want to look at first
> are ./runtests.log and ./syslog. The xfstests results artifacts will
> be in ./btrfs/results-default/.
>
> If you have a wiki page or some other pointer of what tests that you
> expect to fail, I can put them into a btrfs-specific or file system
> configuration specific exclude file. For example, see [1] and [2].
I don't think we do. Usually people keep their own list.
It's also very frequent to have tests fail because the corresponding
patches that fix them were not yet merged, specially for recently
added tests.
>
> [1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/exclude
> [2] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/cfg/bigalloc.exclude
>
> I'm planning on running btrfs and xfs tests more frequently to support
> some $WORK initiatives. So if there are tests which are known
> failures that would be good for me to suppress, and if there are some
> file system configurations that would be useful for me to run, please
> let me know and I'm happy to set them so that gce-xfstests and
> kvm-xfstests can better test btrfs.
>
> Also, I assume you do have some btrfs developers who are regularly
> running xfstests,
I run them daily. And I suppose other developers run them frequently as well.
> so I don't know how helpful this would be to you,
> but given that I'm going to be running the tests *anyway*, if it would
> be helpful for me to forward test results to you, or to only send you
> a note when test regressions show up, I'm happy to do that.
Regarding the failures you got:
btrfs/056 - failure to setup dmflakey, this happens sporadically to me
and others as well, for any test that uses dmflakey and it seems to
happen more often when running dmflakey tests in sequence
btrfs/153 - has been failing for a long time, known issue, just ignore
it for now
btrfs/204 - expected to fail, there's a fix in the mailing list but it
wasn't merged yet (https://patchwork.kernel.org/patch/11357415/)
generic/065 - another failure to create the dmflakey device
generic/260 - expected to fail on btrfs, due to the way space is
allocated and managed in btrfs
generic/475 - this one can fail often for several different reasons.
Some reasons why it can fail are fixed by patches sent to rc3 for
example, other problems like the one you hit (missing file extent
holes) are addressed by a patchset that is in the integration branch
and will likely go into the next merge window
generic/562 - fails with ENOSPC. Doesn't fail for me here, needs to be
investigated.
shared/298 - The test fails with error trying to open a file that
doesn't exists apparently (/root/xfstests/src/parse-extent-tree.awk).
Never seen this failure in my vms, the test always passes for me.
Needs investigation.
Thanks for the report and logs.
>
> Cheers,
>
> - Ted
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs: sleeping function called from invalid context
2020-02-24 0:28 ` Nikolay Borisov
2020-02-24 6:46 ` Theodore Y. Ts'o
@ 2020-02-24 10:11 ` Filipe Manana
1 sibling, 0 replies; 7+ messages in thread
From: Filipe Manana @ 2020-02-24 10:11 UTC (permalink / raw)
To: Nikolay Borisov; +Cc: Theodore Y. Ts'o, linux-btrfs
On Mon, Feb 24, 2020 at 12:30 AM Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> 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.
The problem is that that patch was made against the integration branch
(misc-next) where truncate doesn't use btree search paths with
spinning locks anymore, so it didn't trigger that problem during
development.
The patch was then picked into 5.6-rc2, where we still use spinning
locks, whence people reporting the issue (before Ted, Dave Jones and a
few others had reported it as well).
The solution was to pick a patch from the integration branch into 5.6-rc3:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52e29e331070cd7d52a64cbf1b0958212a340e28
That solves the sleep in invalid context warnings.
>
--
Filipe David Manana,
“Whether you think you can, or you think you can't — you're right.”
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-02-25 9:37 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.