On Wed, Oct 16, 2019 at 04:28:52PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana <fdman...@suse.com>
>
> We were checking for the full fsync flag in the inode before locking the
> inode, which is racy, since at that that time it might not be set but
> after we acquire the inode lock some other task set it. One case where
> this can happen is on a system low on memory and some concurrent task
> failed to allocate an extent map and therefore set the full sync flag on
> the inode, to force the next fsync to work in full mode.
>
> A consequence of missing the full fsync flag set is hitting the problems
> fixed by commit 0c713cbab620 ("Btrfs: fix race between ranged fsync and
> writeback of adjacent ranges"), BUG_ON() when dropping extents from a log
> tree, hitting assertion failures at tree-log.c:copy_items() or all sorts
> of weird inconsistencies after replaying a log due to file extents items
> representing ranges that overlap.
>
> So just move the check such that it's done after locking the inode and
> before starting writeback again.
>
> Fixes: 0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of
> adjacent ranges")
> Signed-off-by: Filipe Manana <fdman...@suse.com>
Oh the joys of fsync and tree-log, thanks for the fix, queued for 5.4-rc.
