Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 13 Aug 2021 14:26:03 +0200
From:   Greg KH <greg@kroah.com>
To:     Anand Jain <anand.jain@oracle.com>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        linux-btrfs@vger.kernel.org, fdmanana@suse.com
Subject: Re: [PATCH stable-5.4.y 0/3] btrfs: backport hang fixes due to
 commit c53e9653605d
Message-ID: <YRZk20TQpSiGiis7@kroah.com>
References: <cover.1628854236.git.anand.jain@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1628854236.git.anand.jain@oracle.com>
Precedence: bulk

On Fri, Aug 13, 2021 at 08:12:22PM +0800, Anand Jain wrote:
> Further to the commit c53e9653605d (btrfs: qgroup: try to flush qgroup 
> space when we get -EDQUOT) there are three fixes as below.
> 
> 6f23277a49e6 btrfs: qgroup: don't commit transaction when we already hold the handle
> 4d14c5cde5c2 btrfs: don't flush from btrfs_delayed_inode_reserve_metadata
> f9baa501b4fd btrfs: fix deadlock when cloning inline extents and using qgroups
> 
> Commits 6f23277a49e6 and 4d14c5cde5c2 above are straightforward and are
> part of this series.
> 
> However, commit f9baa501b4fd above is more complicated to backport.
> Furthermore, the bug mentioned in the commit f9baa501b4fd might not
> trigger on 5.4.y as its related commit 05a5a7621ce66c ("Btrfs: implement
> full reflink support for inline extents") is not backported to 5.4.y.

Queued up, thanks.

greg k-h