On 11.02.20 г. 23:40 ч., Josef Bacik wrote:
> I hit the following warning while running my error injection stress testing
>
> ------------[ cut here ]------------
> WARNING: CPU: 3 PID: 1453 at fs/btrfs/space-info.h:108 btrfs_free_reserved_data_space_noquota+0xfd/0x160 [btrfs]
> RIP: 0010:btrfs_free_reserved_data_space_noquota+0xfd/0x160 [btrfs]
> Call Trace:
> btrfs_free_reserved_data_space+0x4f/0x70 [btrfs]
> __btrfs_prealloc_file_range+0x378/0x470 [btrfs]
> elfcorehdr_read+0x40/0x40
> ? elfcorehdr_read+0x40/0x40
> ? btrfs_commit_transaction+0xca/0xa50 [btrfs]
> ? dput+0xb4/0x2a0
> ? btrfs_log_dentry_safe+0x55/0x70 [btrfs]
> ? btrfs_sync_file+0x30e/0x420 [btrfs]
> ? do_fsync+0x38/0x70
> ? __x64_sys_fdatasync+0x13/0x20
> ? do_syscall_64+0x5b/0x1b0
> ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> ---[ end trace 70ccb5d0fe51151c ]---
>
> This happens if we fail to insert our reserved file extent. At this
> point we've already converted our reservation from ->bytes_may_use to
> ->bytes_reserved. However once we break we will attempt to free
> everything from [cur_offset, end] from ->bytes_may_use, but our extent
> reservation will overlap part of this.
>
> Fix this problem by adding ins.offset (our extent allocation size) to
> cur_offset so we remove the actual remaining part from ->bytes_may_use.
This contradicts the code, you are adding ins.objectid which is the
offset and not the size. This means either the code is buggy.
<snip>
> if (ret) {
> + /*
> + * We've reserved this space, and thus converted it from
> + * ->bytes_may_use to ->bytes_reserved, which we cleanup
> + * here. We need to adjust cur_offset so that we only
> + * drop the ->bytes_may_use for the area we still have
> + * remaining in ->>bytes_may_use.
> + */
> + cur_offset += ins.objectid;
> btrfs_free_reserved_extent(fs_info, ins.objectid,
> ins.offset, 0);
> btrfs_abort_transaction(trans, ret);
>