linux-kernel - Re: [PATCH AUTOSEL 4.19 34/38] btrfs: file: reserve qgroup space after the hole punch range is locked

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]

Message-ID: <20200830144632.GZ8670@sasha-vm>
Date:   Sun, 30 Aug 2020 10:46:32 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Pavel Machek <pavel@....cz>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Qu Wenruo <wqu@...e.com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.19 34/38] btrfs: file: reserve qgroup space
 after the hole punch range is locked

On Sat, Aug 29, 2020 at 02:11:23PM +0200, Pavel Machek wrote:
>Hi!
>
>> [ Upstream commit a7f8b1c2ac21bf081b41264c9cfd6260dffa6246 ]
>>
>> The incoming qgroup reserved space timing will move the data reservation
>> to ordered extent completely.
>>
>> However in btrfs_punch_hole_lock_range() will call
>> btrfs_invalidate_page(), which will clear QGROUP_RESERVED bit for the
>> range.
>>
>> In current stage it's OK, but if we're making ordered extents handle the
>> reserved space, then btrfs_punch_hole_lock_range() can clear the
>> QGROUP_RESERVED bit before we submit ordered extent, leading to qgroup
>> reserved space leakage.
>>
>> So here change the timing to make reserve data space after
>> btrfs_punch_hole_lock_range().
>> The new timing is fine for either current code or the new code.
>
>I'm not sure why this is queued for -stable. It is preparation for
>future work, and that work is not queued for -stable.

So you understand why it was queued: it's preparation for a fix that is
relevant to 4.19 but didn't apply cleanly.

I can look into what happened next week, or if you'd sent me a backport
I'd be happy to take it.

-- 
Thanks,
Sasha