On Mon, Feb 24, 2020 at 12:30 AM Nikolay Borisov <nborisov@xxxxxxxx> 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.”
