aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/iio/trigger/stm32-timer-trigger.c
diff options
context:
space:
mode:
authorJosef Bacik <[email protected]>2020-02-13 15:47:30 +0000
committerDavid Sterba <[email protected]>2020-02-18 23:39:08 +0000
commitbd727173e4432fe6cb70ba108dc1f3602c5409d7 (patch)
tree7dc5a69deb1a811d728b3bcfa21c7e23e8068f87 /drivers/iio/trigger/stm32-timer-trigger.c
parentbtrfs: do not check delayed items are empty for single transaction cleanup (diff)
downloadkernel-bd727173e4432fe6cb70ba108dc1f3602c5409d7.tar.gz
kernel-bd727173e4432fe6cb70ba108dc1f3602c5409d7.zip
btrfs: handle logged extent failure properly
If we're allocating a logged extent we attempt to insert an extent record for the file extent directly. We increase space_info->bytes_reserved, because the extent entry addition will call btrfs_update_block_group(), which will convert the ->bytes_reserved to ->bytes_used. However if we fail at any point while inserting the extent entry we will bail and leave space on ->bytes_reserved, which will trigger a WARN_ON() on umount. Fix this by pinning the space if we fail to insert, which is what happens in every other failure case that involves adding the extent entry. CC: [email protected] # 5.4+ Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Nikolay Borisov <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'drivers/iio/trigger/stm32-timer-trigger.c')
0 files changed, 0 insertions, 0 deletions