Created attachment 273619 [details] Test for stale (removed) files in btrfs directory listings The attached script reliably reproduces the problem on a couple of my machines. By default, it creates files numbered 1 to 350, and then removes every 10th file. On the two machines I've tested, the file named 341 consistently shows up as a stale entry. This problem was first reported at https://bugs.gentoo.org/641262.
I can confirm this on several different systems with kernel 4.14 and 4.15-rc. I could not reproduce this with 4.13.16. So this looks clearly like a regression.
bisect points me to this commit: 23b5ec74943f44378b68c0edd8e210a86318ea5e is the first bad commit commit 23b5ec74943f44378b68c0edd8e210a86318ea5e Author: Josef Bacik <jbacik@fb.com> Date: Mon Jul 24 15:14:25 2017 -0400 btrfs: fix readdir deadlock with pagefault Readdir does dir_emit while under the btree lock. dir_emit can trigger the page fault which means we can deadlock. Fix this by allocating a buffer on opening a directory and copying the readdir into this buffer and doing dir_emit from outside of the tree lock. Thread A readdir <holding tree lock> dir_emit <page fault> down_read(mmap_sem) Thread B mmap write down_write(mmap_sem) page_mkwrite wait_ordered_extents Process C finish_ordered_extent insert_reserved_file_extent try to lock leaf <hang> Signed-off-by: Josef Bacik <jbacik@fb.com> Reviewed-by: David Sterba <dsterba@suse.com> [ copy the deadlock scenario to changelog ] Signed-off-by: David Sterba <dsterba@suse.com> :040000 040000 aeda0fb1a56434e03cf34f5ad07f592de1b5e7e2 76e1d0fe3f1b2bff273b3b38e344da33853cf691 M fs
Sorry about that, I've posted a patch, you can find it here https://patchwork.kernel.org/patch/10181019/
(In reply to Josef Bacik from comment #3) > Sorry about that, I've posted a patch, you can find it here > > https://patchwork.kernel.org/patch/10181019/ Seems to fix it. I can't reproduce it with the test-script anymore.
In that case, can we please close this bug?
Right. Fixed in 4.15 and backproted to 4.14.x.