linux-kernel - Re: [PATCH AUTOSEL 6.0 38/46] btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_CANCEL

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Oct 2022 13:56:36 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Qu Wenruo <quwenruo.btrfs@....com>
Cc:     dsterba@...e.cz, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Qu Wenruo <wqu@...e.com>,
        David Sterba <dsterba@...e.com>, clm@...com,
        josef@...icpanda.com, linux-btrfs@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.0 38/46] btrfs: introduce
 BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN

On Thu, Oct 13, 2022 at 07:12:10AM +0800, Qu Wenruo wrote:
>
>
>On 2022/10/12 20:56, David Sterba wrote:
>>On Tue, Oct 11, 2022 at 10:50:06AM -0400, Sasha Levin wrote:
>>>From: Qu Wenruo <wqu@...e.com>
>>>
>>>[ Upstream commit e562a8bdf652b010ce2525bcf15d145c9d3932bf ]
>>>
>>>Introduce a new runtime flag, BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN,
>>>which will inform qgroup rescan to cancel its work asynchronously.
>>>
>>>This is to address the window when an operation makes qgroup numbers
>>>inconsistent (like qgroup inheriting) while a qgroup rescan is running.
>>>
>>>In that case, qgroup inconsistent flag will be cleared when qgroup
>>>rescan finishes.
>>>But we changed the ownership of some extents, which means the rescan is
>>>already meaningless, and the qgroup inconsistent flag should not be
>>>cleared.
>>>
>>>With the new flag, each time we set INCONSISTENT flag, we also set this
>>>new flag to inform any running qgroup rescan to exit immediately, and
>>>leaving the INCONSISTENT flag there.
>>>
>>>The new runtime flag can only be cleared when a new rescan is started.
>>
>>Qu, does this patch make sense for stable on itself? It was part of a
>>series adding some new flags and the sysfs knob.  As I read it there's a
>>case where it can affect how the rescan is done and that it can be
>>cancelled but still am not sure if it's worth the backport.
>
>Considering the qgroup still lacks a way to handle large subvolume drop,
>and a lot of things can mark qgroup inconsistent halfway, I think
>backporting this patch itself is not that bad.
>
>The problem is, why only backporting this one?
>
>To me, it would make more sense to backport either all or none.
>
>Sure, if we can cancel rescan it's an improvement, but rescan itself is
>already relatively cheap compared to other qgroup operations.
>Thus I prefer to backport all the qgroup patches.

I'll drop this one and happily take a series if you want to send one
out.

-- 
Thanks,
Sasha