RE: Re: RE: [PATCH] Revert "ceph: when filling trace, call ceph_get_inode outside of mutexes"

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Tue, 2026-04-28 at 05:31 +0000, 李磊 wrote:
> 
> > > 

<skipped>

> > 
> > As far as I can see, I was able to reproduce the issue without your patch
> > applied. It looks like I was "lucky" to reproduce the issue. I need to take a
> > deeper look into the issue. But your patch is not responsible for the issue. Let
> > me spend some time to analyze the issue reason and environment.
> > 
> > Have you able to reproduce the issue on your side?
> 
> I’ve tried generic/701 again for several times, but no issues occurred.
> 

I assume that running only generic/701 test-case alone cannot reproduce the
issue. My understanding is that the whole auto group needs to be executed.
Somehow, I was lucky enough to reproduce the issue. :)

> Judging only from the stack trace, I believe it’s a deadlock between
> writeback and memory reclaiming. This dependency chain is as follows
> 
> 1. Several D threads are waiting for the osdc->lock to be released. 
> 2. The osdc->lock is held by kworker/u32:0:241092 which is performing writeback,
>    and kworker/u32:0:241092 is asking for con->mutex to send_request.
> 3. The con->mutex is held by kworker/7:4:308292 which is currently calling do_sendmsg()
> 
> Because of memory shortage, step 3 has to reclaim memory and wait for step 2 to writeback
> And free some folios. But step 2 is blocked by con->mutex which is already held by step3.
> 

I am going to take a deeper look into the issue today. But, probably, one day
could be not enough. :)

Thanks,
Slava.