Right. It happened even without this patch but we just know it now.
In the original investigations of the patch, the moment you copy a
device image into another device, the autoscan would scan the new
device into the btrfs kernel and created a mess. Now with this patch
we won't replace the device
From: Chris Mason
The btrfs writepages function collects a large range of pages flagged
for delayed allocation, and then sends them down through the COW code
for processing. When compression is on, we allocate one async_cow
structure for every 512K, and then run those pages through the
compressi
Hello,
This patchset contains only the btrfs part of the following patchset.
[1] [PATCHSET v2 btrfs/for-next] blkcg, btrfs: fix cgroup writeback support
The block part has already been applied to
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/
for-linus
with some na
From: Chris Mason
btrfs_schedule_bio() hands IO off to a helper thread to do the actual
submit_bio() call. This has been used to make sure async crc and
compression helpers don't get stuck on IO submission. To maintain good
performance, over time the IO submission threads duplicated some IO
sch
From: Chris Mason
Async CRCs and compression submit IO through helper threads, which
means they have IO priority inversions when cgroup IO controllers are
in use.
This flags all of the writes submitted by btrfs helper threads as
REQ_CGROUP_PUNT. submit_bio() will punt these to dedicated per-blk
From: Chris Mason
extent_write_locked_range() is used when we're falling back to buffered
IO from inside of compression. It allocates its own wbc and should
associate it with the inode's i_wb to make sure the IO goes down from
the correct cgroup.
Signed-off-by: Chris Mason
Reviewed-by: Josef B
From: Chris Mason
Now that we're not using btrfs_schedule_bio() anymore, delete all the
code that supported it.
Signed-off-by: Chris Mason
Reviewed-by: Josef Bacik
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/disk-io.c | 13 +--
fs/btrfs/super.c | 1 -
fs/btrfs/volumes.c | 209 --
Anand's Nov 2018 patch "btrfs: harden agaist duplicate fsid" has
recently percolated through to my Debian buster server system.
And it is spamming my log files.
Each of my btrfs filesystem devices logs 4 messages every 2 minutes.
Here is an example of the 4 messages related to one device:
Jul 10
On 10.07.19 г. 15:02 ч., Qu Wenruo wrote:
>
>
> On 2019/7/10 下午7:19, Nikolay Borisov wrote:
>>
>>
> [...]
>>> +static int check_cross_tree_key_order(struct extent_buffer *left,
>>> + struct extent_buffer *right)
>>> +{
>>> + struct btrfs_key left_last;
>>> +
On 2019/7/10 下午7:19, Nikolay Borisov wrote:
>
>
[...]
>> +static int check_cross_tree_key_order(struct extent_buffer *left,
>> + struct extent_buffer *right)
>> +{
>> +struct btrfs_key left_last;
>> +struct btrfs_key right_first;
>> +int level = btrfs
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> [BUG]
> With crafted image, btrfs can panic at btrfs_del_csums().
> kernel BUG at fs/btrfs/ctree.c:3188!
> invalid opcode: [#1] SMP PTI
> CPU: 0 PID: 1156 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
> RIP: 0010:btrfs_set_item_key_safe+
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> [BUG]
> With crafted image, btrfs can panic at insert_inline_extent_backref():
> kernel BUG at fs/btrfs/extent-tree.c:1857!
> invalid opcode: [#1] SMP PTI
> CPU: 0 PID: 1117 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
> RIP: 0010:inser
On 2019/7/10 下午6:42, Nikolay Borisov wrote:
>
>
[...]
>>
>> +/*
>> + * Check if the [start, start + len) range is valid before reading/writing
>> + * the eb.
>> + *
>> + * Caller should not touch the dst/src memory if this function returns
>> error.
>> + */
>> +static int check_eb_range(cons
On 2019/7/10 下午6:48, Nikolay Borisov wrote:
>
>
> On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
>> __btrfs_free_extent() is one of the best cases to show how optimization
>> could make a function hard to read.
>>
>> In fact __btrfs_free_extent() is only doing two major works:
>> 1. Reduce the refs
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> [BUG]
> With crafted image, btrfs will panic at btree operations:
> kernel BUG at fs/btrfs/ctree.c:3894!
> invalid opcode: [#1] SMP PTI
> CPU: 0 PID: 1138 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
> RIP: 0010:__push_leaf_left+0x6b6/0
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> __btrfs_free_extent() is one of the best cases to show how optimization
> could make a function hard to read.
>
> In fact __btrfs_free_extent() is only doing two major works:
> 1. Reduce the refs number of an extent backref
>Either it's an inlined
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> Although we have start, len check for extent buffer reader/write (e.g.
> read_extent_buffer()), those checks has its limitations:
> - No overflow check
> Values like start = 1024 len = -1024 can still pass the basic
>(start + len) > eb->len check
Although we have start, len check for extent buffer reader/write (e.g.
read_extent_buffer()), those checks has its limitations:
- No overflow check
Values like start = 1024 len = -1024 can still pass the basic
(start + len) > eb->len check.
- Checks are not consistent
For read_extent_buffer
__btrfs_free_extent() is one of the best cases to show how optimization
could make a function hard to read.
In fact __btrfs_free_extent() is only doing two major works:
1. Reduce the refs number of an extent backref
Either it's an inlined extent backref (inside EXTENT/METADATA item) or
a key
[BUG]
With crafted image, btrfs can panic at btrfs_del_csums().
kernel BUG at fs/btrfs/ctree.c:3188!
invalid opcode: [#1] SMP PTI
CPU: 0 PID: 1156 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
RIP: 0010:btrfs_set_item_key_safe+0x16c/0x180
Code: b7 48 8d 7d bf 4c 89 fe 48 89 45 c8 0
[BUG]
With crafted image, btrfs will panic at btree operations:
kernel BUG at fs/btrfs/ctree.c:3894!
invalid opcode: [#1] SMP PTI
CPU: 0 PID: 1138 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
RIP: 0010:__push_leaf_left+0x6b6/0x6e0
Code: 00 00 48 98 48 8d 04 80 48 8d 74 80 65 e8 42
[BUG]
With crafted image, btrfs can panic at insert_inline_extent_backref():
kernel BUG at fs/btrfs/extent-tree.c:1857!
invalid opcode: [#1] SMP PTI
CPU: 0 PID: 1117 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
RIP: 0010:insert_inline_extent_backref+0xcc/0xe0
Code: 45 20 49 8b 7e
Another wave of defence enhancment, including:
- Enhanced eb accessors
Not really needed for the fuzzed images, as 448de471cd4c
("btrfs: Check the first key and level for cached extent buffer")
already fixed half of the reported images.
Just add a final layer of safe net.
- BUG_ON() hunt
23 matches
Mail list logo
