Messages in this thread | | | Date | Mon, 22 Oct 2018 20:22:43 +0200 | From | David Sterba <> | Subject | Re: Circular lock dep in btrfs triggered by shrinker |
| |
On Mon, Oct 22, 2018 at 03:07:26AM -0700, Olof Johansson wrote: > I hit the below circular locking dependency. Seems like the assumption made in > 712e36c5f2a7fa56 ("btrfs: use GFP_KERNEL in btrfs_alloc_inode") either isn't > true, or has since changed?
I think it must have been there from the beginning. There were reports of this lockdep warning like the below and IIRC a few more (https://lkml.kernel.org/r/20180627120523.GA2287@suse.cz), but without a resolution.
Incidentally, there was a fix that's now in the 4.20 pull and only after I had seen your report I realized that it was the fix for the warning:
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/commit/?h=for-4.20-part1&id=84de76a2fb217dc1b6bc2965cc397d1648aa1404
It disables the filesystem allocations using the memalloc_nofs mechanism around free space inode allocation, while my original patch expected only regular inodes created by VFS.
> ====================================================== > WARNING: possible circular locking dependency detected > 4.19.0 #25 Not tainted > ------------------------------------------------------ > kswapd0/414 is trying to acquire lock: > 000000008b8f1971 (&delayed_node->mutex){+.+.}, at: __btrfs_release_delayed_node+0x35/0x1e0 > but task is already holding lock: > 00000000032f657e (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30 > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > -> #3 (fs_reclaim){+.+.}: > kmem_cache_alloc+0x24/0x270 > btrfs_alloc_inode+0x1f/0x260 > alloc_inode+0x13/0x80 > iget5_locked+0x3f/0x80 > btrfs_iget+0x52/0x680 > __lookup_free_space_inode+0xd9/0x110
The patch adds memalloc_nofs into ^^^^. It's scheduled for stable so the warning will disappear eventually, thanks for the report.
| |