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.
