From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz
Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
Qu Wenruo <wqu@suse.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Rongrong <i@rong.moe>
Subject: Re: [PATCH] btrfs: scrub: avoid use-after-free when chunk end is not 64K aligned
Date: Wed, 17 Jan 2024 06:36:00 +1030 [thread overview]
Message-ID: <49056bc2-55ba-4f09-9a30-0caf4016bfc2@gmx.com> (raw)
In-Reply-To: <20240116182807.GB31555@twin.jikos.cz>
On 2024/1/17 04:58, David Sterba wrote:
> On Tue, Jan 16, 2024 at 09:20:58AM +1030, Qu Wenruo wrote:
>>
>>
>> On 2024/1/15 22:39, Johannes Thumshirn wrote:
>> [...]
>>>
>>>> - Make sure scrub_submit_initial_read() only to read the chunk range
>>>> This is done by calculating the real number of sectors we need to
>>>> read, and add sector-by-sector to the bio.
>>>
>>> Why can't you do it the same way the RST version does it by checking the
>>> extent_sector_bitmap and then add sector-by-sector from it?
>>
>> Sure, we can, although the whole new scrub code is before RST, and at
>> that time, the whole 64K read behavior is considered as a better option,
>> as it reduces the IOPS for a fragmented stripe.
>
> I'd like to keep the scrub fix separte from the RST code, even if
> there's a chance for some code sharing or reuse. The scrub fix needs to
> be backported so it's better to keep it independent.
So do I need to split the fix, so that the first part would be purely
for the non-RST scrub part, and then a small fix to the RST part?
I can try to do that, but since we need to touch the read endio function
anyway, it may mean if we don't do it properly, it may break bisection.
Thus I'd prefer to do a manual backport for the older branches without
the RST code.
Thanks,
Qu
>
> The change itself looks as an enhancement of the existing code so it's
> "obvious" and does not need any preparatory patches.
>
next prev parent reply other threads:[~2024-01-16 20:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 10:19 [PATCH] btrfs: scrub: avoid use-after-free when chunk end is not 64K aligned Qu Wenruo
2024-01-15 12:09 ` Johannes Thumshirn
2024-01-15 22:50 ` Qu Wenruo
2024-01-16 18:28 ` David Sterba
2024-01-16 20:06 ` Qu Wenruo [this message]
2024-01-17 0:55 ` David Sterba
2024-01-17 2:23 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49056bc2-55ba-4f09-9a30-0caf4016bfc2@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=dsterba@suse.cz \
--cc=i@rong.moe \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox