Revision tags: v5.15.68 |
|
#
bd015294 |
| 09-Sep-2022 |
Josef Bacik <josef@toxicpanda.com> |
btrfs: replace delete argument with EXTENT_CLEAR_ALL_BITS
Instead of taking up a whole argument to indicate we're clearing everything in a range, simply add another EXTENT bit to control this, and t
btrfs: replace delete argument with EXTENT_CLEAR_ALL_BITS
Instead of taking up a whole argument to indicate we're clearing everything in a range, simply add another EXTENT bit to control this, and then update all the callers to drop this argument from the clear_extent_bit variants.
Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
#
dbbf4992 |
| 09-Sep-2022 |
Josef Bacik <josef@toxicpanda.com> |
btrfs: remove the wake argument from clear_extent_bits
This is only used in the case that we are clearing EXTENT_LOCKED, so infer this value from the bits passed in instead of taking it as an argume
btrfs: remove the wake argument from clear_extent_bits
This is only used in the case that we are clearing EXTENT_LOCKED, so infer this value from the bits passed in instead of taking it as an argument.
Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20 |
|
#
6d3b050e |
| 03-Feb-2022 |
Filipe Manana <fdmanana@suse.com> |
btrfs: assert we have a write lock when removing and replacing extent maps
Removing or replacing an extent map requires holding a write lock on the extent map's tree. We currently do that everywhere
btrfs: assert we have a write lock when removing and replacing extent maps
Removing or replacing an extent map requires holding a write lock on the extent map's tree. We currently do that everywhere, except in one of the self tests, where it's harmless since there's no concurrency.
In order to catch possible races in the future, assert that we are holding a write lock on the extent map tree before removing or replacing an extent map in the tree, and update the self test to obtain a write lock before removing extent maps.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
#
199257a7 |
| 11-Feb-2022 |
Qu Wenruo <wqu@suse.com> |
btrfs: defrag: don't use merged extent map for their generation check
For extent maps, if they are not compressed extents and are adjacent by logical addresses and file offsets, they can be merged i
btrfs: defrag: don't use merged extent map for their generation check
For extent maps, if they are not compressed extents and are adjacent by logical addresses and file offsets, they can be merged into one larger extent map.
Such merged extent map will have the higher generation of all the original ones.
But this brings a problem for autodefrag, as it relies on accurate extent_map::generation to determine if one extent should be defragged.
For merged extent maps, their higher generation can mark some older extents to be defragged while the original extent map doesn't meet the minimal generation threshold.
Thus this will cause extra IO.
So solve the problem, here we introduce a new flag, EXTENT_FLAG_MERGED, to indicate if the extent map is merged from one or more ems.
And for autodefrag, if we find a merged extent map, and its generation meets the generation requirement, we just don't use this one, and go back to defrag_get_extent() to read extent maps from subvolume trees.
This could cause more read IO, but should result less defrag data write, so in the long run it should be a win for autodefrag.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65 |
|
#
4c664611 |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this
btrfs: rename btrfs_bio to btrfs_io_context
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
d2faf8ed |
| 15-Sep-2021 |
Qu Wenruo <wqu@suse.com> |
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based
btrfs: rename btrfs_bio to btrfs_io_context
[ Upstream commit 4c6646117912397d026d70c04d92ec1599522e9f ]
The structure btrfs_bio is used by two different sites:
- bio->bi_private for mirror based profiles For those profiles (SINGLE/DUP/RAID1*/RAID10), this structures records how many mirrors are still pending, and save the original endio function of the bio.
- RAID56 code In that case, RAID56 only utilize the stripes info, and no long uses that to trace the pending mirrors.
So btrfs_bio is not always bind to a bio, and contains more info for IO context, thus renaming it will make the naming less confusing.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
9ad37bb3 |
| 22-Jan-2021 |
Nikolay Borisov <nborisov@suse.com> |
btrfs: fix parameter description of btrfs_add_extent_mapping
This fixes the following compiler warnings:
fs/btrfs/extent_map.c:601: warning: Function parameter or member 'fs_info' not described in
btrfs: fix parameter description of btrfs_add_extent_mapping
This fixes the following compiler warnings:
fs/btrfs/extent_map.c:601: warning: Function parameter or member 'fs_info' not described in 'btrfs_add_extent_mapping' fs/btrfs/extent_map.c:601: warning: Function parameter or member 'em_tree' not described in 'btrfs_add_extent_mapping' fs/btrfs/extent_map.c:601: warning: Function parameter or member 'em_in' not described in 'btrfs_add_extent_mapping' fs/btrfs/extent_map.c:601: warning: Function parameter or member 'start' not described in 'btrfs_add_extent_mapping' fs/btrfs/extent_map.c:601: warning: Function parameter or member 'len' not described in 'btrfs_add_extent_mapping'
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
#
401bd2dd |
| 22-Jan-2021 |
Nikolay Borisov <nborisov@suse.com> |
btrfs: document modified parameter of add_extent_mapping
Fixes fs/btrfs/extent_map.c:399: warning: Function parameter or member 'modified' not described in 'add_extent_mapping'
Reviewed-by: Johanne
btrfs: document modified parameter of add_extent_mapping
Fixes fs/btrfs/extent_map.c:399: warning: Function parameter or member 'modified' not described in 'add_extent_mapping'
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17 |
|
#
ac05ca91 |
| 31-Jan-2020 |
Filipe Manana <fdmanana@suse.com> |
Btrfs: fix race between using extent maps and merging them
We have a few cases where we allow an extent map that is in an extent map tree to be merged with other extents in the tree. Such cases incl
Btrfs: fix race between using extent maps and merging them
We have a few cases where we allow an extent map that is in an extent map tree to be merged with other extents in the tree. Such cases include the unpinning of an extent after the respective ordered extent completed or after logging an extent during a fast fsync. This can lead to subtle and dangerous problems because when doing the merge some other task might be using the same extent map and as consequence see an inconsistent state of the extent map - for example sees the new length but has seen the old start offset.
With luck this triggers a BUG_ON(), and not some silent bug, such as the following one in __do_readpage():
$ cat -n fs/btrfs/extent_io.c 3061 static int __do_readpage(struct extent_io_tree *tree, 3062 struct page *page, (...) 3127 em = __get_extent_map(inode, page, pg_offset, cur, 3128 end - cur + 1, get_extent, em_cached); 3129 if (IS_ERR_OR_NULL(em)) { 3130 SetPageError(page); 3131 unlock_extent(tree, cur, end); 3132 break; 3133 } 3134 extent_offset = cur - em->start; 3135 BUG_ON(extent_map_end(em) <= cur); (...)
Consider the following example scenario, where we end up hitting the BUG_ON() in __do_readpage().
We have an inode with a size of 8KiB and 2 extent maps:
extent A: file offset 0, length 4KiB, disk_bytenr = X, persisted on disk by a previous transaction
extent B: file offset 4KiB, length 4KiB, disk_bytenr = X + 4KiB, not yet persisted but writeback started for it already. The extent map is pinned since there's writeback and an ordered extent in progress, so it can not be merged with extent map A yet
The following sequence of steps leads to the BUG_ON():
1) The ordered extent for extent B completes, the respective page gets its writeback bit cleared and the extent map is unpinned, at that point it is not yet merged with extent map A because it's in the list of modified extents;
2) Due to memory pressure, or some other reason, the MM subsystem releases the page corresponding to extent B - btrfs_releasepage() is called and returns 1, meaning the page can be released as it's not dirty, not under writeback anymore and the extent range is not locked in the inode's iotree. However the extent map is not released, either because we are not in a context that allows memory allocations to block or because the inode's size is smaller than 16MiB - in this case our inode has a size of 8KiB;
3) Task B needs to read extent B and ends up __do_readpage() through the btrfs_readpage() callback. At __do_readpage() it gets a reference to extent map B;
4) Task A, doing a fast fsync, calls clear_em_loggin() against extent map B while holding the write lock on the inode's extent map tree - this results in try_merge_map() being called and since it's possible to merge extent map B with extent map A now (the extent map B was removed from the list of modified extents), the merging begins - it sets extent map B's start offset to 0 (was 4KiB), but before it increments the map's length to 8KiB (4kb + 4KiB), task A is at:
BUG_ON(extent_map_end(em) <= cur);
The call to extent_map_end() sees the extent map has a start of 0 and a length still at 4KiB, so it returns 4KiB and 'cur' is 4KiB, so the BUG_ON() is triggered.
So it's dangerous to modify an extent map that is in the tree, because some other task might have got a reference to it before and still using it, and needs to see a consistent map while using it. Generally this is very rare since most paths that lookup and use extent maps also have the file range locked in the inode's iotree. The fsync path is pretty much the only exception where we don't do it to avoid serialization with concurrent reads.
Fix this by not allowing an extent map do be merged if if it's being used by tasks other then the one attempting to merge the extent map (when the reference count of the extent map is greater than 2).
Reported-by: ryusuke1925 <st13s20@gm.ibaraki-ct.ac.jp> Reported-by: Koki Mitani <koki.mitani.xg@hco.ntt.co.jp> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206211 CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12 |
|
#
a019e9e1 |
| 30-Aug-2019 |
David Sterba <dsterba@suse.com> |
btrfs: remove extent_map::bdev
We can now remove the bdev from extent_map. Previous patches made sure that bio_set_dev is correctly in all places and that we don't need to grab it from latest_bdev o
btrfs: remove extent_map::bdev
We can now remove the bdev from extent_map. Previous patches made sure that bio_set_dev is correctly in all places and that we don't need to grab it from latest_bdev or pass it around inside the extent map.
Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|
Revision tags: v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1 |
|
#
c3e14909 |
| 10-May-2019 |
David Sterba <dsterba@suse.com> |
btrfs: assert extent_map bdevs and lookup_map and split
This is a preparatory patch for removing extent_map::bdev. There's some history behind the code so this is only precaution to catch if things
btrfs: assert extent_map bdevs and lookup_map and split
This is a preparatory patch for removing extent_map::bdev. There's some history behind the code so this is only precaution to catch if things break before the actual removal happens.
Logically, comparing a raw low-level block device (bdev) does not make sense for extent maps (high-level objects). This had no effect in practice but was quite confusing in the code. The lookup_map is set iff EXTENT_FLAG_FS_MAPPING is set.
The two pointers were stored in the same bytes and used potentially in two meanings. Now they're split, so the asserts are in place to check that the condition will not change.
The lookup map pointer misused bdev, this has been changed in commit 95617d69326c ("btrfs: cleanup, stop casting for extent_map->lookup everywhere") to the explicit type. But the semantics hasn't changed and bdev was not actually used to decide if maps are mergeable.
Signed-off-by: David Sterba <dsterba@suse.com>
show more ...
|