Re: [BUG REPORT] Deadlock when executing xfs/168 on XFS' previous for-next

[Chandan Babu R <chandanbabu@kernel.org>]

On Tue, Mar 05, 2024 at 05:32:45 PM +1100, Dave Chinner wrote:
> On Tue, Mar 05, 2024 at 10:18:45AM +0530, Chandan Babu R wrote:

>> [18460.730782] XFS (loop5): Mounting V5 Filesystem 68e1b71a-583f-41c8-8194-bb82c4e2fe0d
>> [18460.742765] XFS (loop5): Ending clean mount
>> [18461.786504] XFS (loop5): EXPERIMENTAL online shrink feature in use. Use at your own risk!
>> [18679.145200] INFO: task fsstress:230900 blocked for more than 122 seconds.
>> [18679.147164]       Tainted: G        W          6.8.0-rc6+ #1
>> [18679.148710] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> [18679.150423] task:fsstress        state:D stack:0     pid:230900 tgid:230900 ppid:230899 flags:0x00000002
>> [18679.152186] Call Trace:
>> [18679.153257]  <TASK>
>
> Ugh - those stack traces are unreadable because of all the unwinder
> false positives (all the ? entries) in them. Can you either change
> the unwinder config in your builds to get rid of them or
> post-process the stack dumps so they are human readable?
>
> /me selects everything and runs `:'<,'>!grep -v "?"` make it
> somewhat more readable and then trims manually:
>

I am sorry about that. I should have cleaned up the irrelevant entries in the
call traces.

-- 
Chandan