Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: iamhswang@gmail.com
Cc: linux-btrfs@vger.kernel.org, clm@fb.com, josef@toxicpanda.com,
	dsterba@suse.com, wqu@suse.com, boris@bur.io,
	linux-kernel@vger.kernel.org, Haisu Wang <haisuwang@tencent.com>
Subject: Re: [PATCH v2 0/2] btrfs: fix the length of reserved qgroup to free
Date: Wed, 30 Oct 2024 01:13:25 +0100	[thread overview]
Message-ID: <20241030001325.GW31418@twin.jikos.cz> (raw)
In-Reply-To: <20241025065448.3231672-1-haisuwang@tencent.com>

On Fri, Oct 25, 2024 at 02:54:39PM +0800, iamhswang@gmail.com wrote:
> From: Haisu Wang <haisuwang@tencent.com>
> 
> This patch set fixes the inconsistent region size of qgroup data.
> 
> The first patch ("btrfs: fix the length of reserved qgroup to free")
> is enough to work together with the fix of CVE-2024-46733 to port
> to all effected stable release branches.
> The second patch is aim to make the reserved/alloced region more clear
> to ease the error handling clean up. The start mark no longer advanced
> in error handling, also the cur_alloc_size can represent the ram size
> and dealloc area.
> 
> I am able to run fstest generic/475 for hundred times with quota enabled,
> half of the tests modified by removing sleep time. About one tenth of
> the tests are enter to the error handling process due to fail to reserve
> extent. Though I didin't find a proper reproducer to enter all possible
> error conditions to simulate alloc/checksum failure.
> 
> [CHANGELOG]
> V2:
> - Clear the alloc and error handling path and keep the start unchanged
> - Patch ("btrfs: fix the length of reserved qgroup to free") unchanged
>   to make CVE-2024-46733 related fix as simple as possible
> 
> V1:
> Adjust the length of untouch region to free.
> https://lore.kernel.org/linux-btrfs/20241008064849.1814829-1-haisuwang@tencent.com/T/#u
> 
> Haisu Wang (2):
>   btrfs: fix the length of reserved qgroup to free
>   btrfs: simplify regions mark and keep start unchanged in err handling

Thanks, patches added to for-next, with some minor adjustments.

      parent reply	other threads:[~2024-10-30  0:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  6:54 [PATCH v2 0/2] btrfs: fix the length of reserved qgroup to free iamhswang
2024-10-25  6:54 ` [PATCH 1/2] " iamhswang
2024-10-25  6:54 ` [PATCH 2/2] btrfs: simplify regions mark and keep start unchanged in err handling iamhswang
2024-10-30  3:01   ` Qu Wenruo
2024-10-30  3:22     ` hs wang
2024-10-30 15:28     ` David Sterba
2024-10-30 22:01       ` Qu Wenruo
2024-10-30  0:13 ` David Sterba [this message]

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=20241030001325.GW31418@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=boris@bur.io \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=haisuwang@tencent.com \
    --cc=iamhswang@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@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