From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bob Peterson <rpeterso@redhat.com>
Date: Mon, 26 Jul 2021 12:35:34 -0500
Subject: [Cluster-devel] gfs2 hang in xfstests generic/361
In-Reply-To: <20210726140058.GA9206@lst.de>
References: <20210726140058.GA9206@lst.de>
Message-ID: <2c552824-47bd-a757-3314-1d539908815a@redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On 7/26/21 9:00 AM, Christoph Hellwig wrote:
> I noticed this hang while testing the iomap_iter series on gfs2,
> but it also reproduces on 5.14-rc3.  This is running locally with
> "-O -p lock_nolock":
> 
(snip)
> generic/361 files ... [ 1479.222703] run fstests generic/361 at 2021-07-26 13:57:10
(snip)
> [ 1491.752587] =============================
> [ 1491.753403] [ BUG: Invalid wait context ]
> [ 1491.754122] 5.14.0-rc2+ #47 Not tainted
> [ 1491.754860] -----------------------------
> [ 1491.755563] kworker/2:1H/1975 is trying to lock:

Hi again Christoph,

Apparently the reason I haven't been seeing this problem myself is
because I've been testing code in an experimental branch in linux-gfs2,
and one of my other patches already fixed the problem. I just pushed my
experimental branch to linux-gfs2/for-next.next4 and the patch that
fixes it is 631e950b2eeb ("gfs2: fix deadlock in gfs2_ail1_empty
withdraw"). Perhaps you can cherry-pick that patch (and others if 
warranted) into your test branch and see if it behaves itself?

Regards,

Bob Peterson