linux-kernel - Re: [PATCH v2 0/5] btrfs: fix relocation on RAID stripe-tree filesystems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5382a028-5a2f-4d96-b522-3865c7eea31d@wdc.com>
Date: Wed, 31 Jul 2024 20:13:23 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Qu Wenruo <quwenruo.btrfs@....com>, Johannes Thumshirn <jth@...nel.org>,
	Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba
	<dsterba@...e.com>
CC: "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Johannes
 Thumshirn <jthumshirn@....com>, Filipe Manana <fdmanana@...e.com>
Subject: Re: [PATCH v2 0/5] btrfs: fix relocation on RAID stripe-tree
 filesystems

On 30.07.24 23:34, Qu Wenruo wrote:
> 
> 
> 在 2024/7/30 20:03, Johannes Thumshirn 写道:
>> When doing relocation on RST backed filesystems, there is a possibility of
>> a scatter-gather list corruption.
>>
>> See patch 4 for details.
>>
>> CI Link: https://github.com/btrfs/linux/actions/runs/10143804038
>>
>> ---
>> Changes in v2:
>> - Change RST lookup error message to debug
>> - Link to v1: https://lore.kernel.org/r/20240729-debug-v1-0-f0b3d78d9438@kernel.org
>>
>> ---
>> Johannes Thumshirn (5):
>>         btrfs: don't dump stripe-tree on lookup error
>>         btrfs: rename btrfs_io_stripe::is_scrub to rst_search_commit_root
>>         btrfs: set rst_search_commit_root in case of relocation
>>         btrfs: don't readahead the relocation inode on RST
>>         btrfs: change RST lookup error message to debug
> 
> Reviewed-by: Qu Wenruo <wqu@...e.com>
> 
> The solution looks fine to me, but I have one extra question related to
> the readahead.
> 
>     Does the readahead fail because it's reading some range not covered by
>     any extent?

TBH I'm not 100% certain how it happens. The readahead fails because we 
have a RST lookup error. This could be because of preallocated extents 
(Josef's assumption) or something else.

I could not 100% verify that it is only preallocated extents, but my 
debug code could've been incomplete as well.

I would really really love to have a better explanation, but I don't 
have one yet.

I'm sorry to disappoint you here.

Byte,
	Johannes