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.