[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230711011338.GB683098@onthe.net.au>
Date: Tue, 11 Jul 2023 11:13:38 +1000
From: Chris Dunlop <chris@...he.net.au>
To: Bagas Sanjaya <bagasdotme@...il.com>
Cc: Linux XFS <linux-xfs@...r.kernel.org>,
Dave Chinner <dchinner@...hat.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Linux Stable <stable@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Regressions <regressions@...ts.linux.dev>
Subject: Re: rm hanging, v6.1.35
On Tue, Jul 11, 2023 at 07:53:35AM +0700, Bagas Sanjaya wrote:
> On Tue, Jul 11, 2023 at 07:53:54AM +1000, Chris Dunlop wrote:
>> Hi,
>>
>> This box is newly booted into linux v6.1.35 (2 days ago), it was previously
>> running v5.15.118 without any problems (other than that fixed by
>> "5e672cd69f0a xfs: non-blocking inodegc pushes", the reason for the
>> upgrade).
>>
>> I have rm operations on two files that have been stuck for in excess of 22
>> hours and 18 hours respectively:
>
> Smells like regression resurfaced, right? I mean, does 5e672cd69f0a53 not
> completely fix your reported blocking regression earlier?
>
> I'm kinda confused...
It looks like a completely different problem. I was wanting 5e672cd69f0a53
as a resolution to this:
https://lore.kernel.org/all/20220510215411.GT1098723@dread.disaster.area/T/
In that case there were kernel stacks etc. showing inodegc stuff, and the
problem eventually resolved itself once the massive amount of work had
been processed (5e672cd69f0a53 puts that work into the background).
In this case it looks like it's just a pure hang or deadlock - there's
apparently nothing happening.
Cheers,
Chris
Powered by blists - more mailing lists