Re: [PATCH] fs: revert insert_inode_locked() eviction wait change and explain why

[Jan Kara]

On Tue 17-03-26 14:44:54, Mateusz Guzik wrote:
> On Tue, Mar 17, 2026 at 2:39 PM Jan Kara <jack@xxxxxxx> wrote:
> >
> > On Tue 17-03-26 14:12:48, Mateusz Guzik wrote:
> > > On Tue, Mar 17, 2026 at 2:01 PM Jan Kara <jack@xxxxxxx> wrote:
> > > >
> > > > On Mon 16-03-26 11:33:05, Mateusz Guzik wrote:
> > > > > It causes a deadlock, reproducer can be found here:
> > > > > https://lore.kernel.org/linux-fsdevel/abNvb2PcrKj1FBeC@ly-workstation/
> > > > >
> > > > > The real bug is in ext4, but I'm not digging into it and a working order
> > > > > needs to be restored.
> > > >
> > > > I can dig into that. I expect ext4 ends up calling find_inode() from its
> > > > ext4_evict_inode() handler or something like that? I was searching for such
> > > > occurrence for a while but I didn't find it so can you share where ext4
> > > > blocked? Because the stacktraces from the original report just show the
> > > > journalling machinery hangs but those are only side-effects of somebody
> > > > hanging in ext4 with the transaction handle started... Thanks!
> > > all traces attached
> >
> > Thanks! OK, for reference the inode has been marked as 'sync' so
> >
> > ext4_evict_inode() -> ext4_journal_stop()
> >
> > ends up waiting for transaction commit. However ext4_new_inode() calls
> > insert_inode_locked() with started transaction handle and thus waits for
> > the freeing inode with the handle started. Classical ABBA deadlock. I'll
> > think how we could sensibly fix this in ext4.
> >
> 
> Do you think fixing the actual bug is viable for 7.0? The above revert
> seems most prudent for the time being.

I have an idea for relatively easy fix within ext4. I'll discuss it today
on our ext4 developers call and if it works out, I think we can fix ext4
for 7.0. I agree if it doesn't work out, we should revert for now. I'll let
you know how it worked out.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR