[syzbot] [ntfs3?] INFO: task hung in __start_renaming

[Christian Brauner]

On Mon, Nov 24, 2025 at 10:21:07AM +0100, Mateusz Guzik wrote:
> On Mon, Nov 24, 2025 at 10:01:53AM +0100, Mateusz Guzik wrote:
> > sigh, so it *is* my patch, based on syzbot testing specifically on
> > directory locking vs inode branches, but I don't see why.
> > 
> > I take it the open() codepath took the rwsem, hence the rename is
> > sleeping. Given that all reproducers find it *on* cpu, it may be this
> > is busy looping for some reason.
> > 
> > I don't have time to dig more into it right now, so I think it would
> > be best to *drop* my patch for the time being. Once I figure it out
> > I'll send a v2.
> > 
> 
> good news, now that I gave up I found it.
> 
> insert_inode_locked() is looping indefinitely an inode which is no
> longer I_NEW or I_CREATING.
> 
> In stock kernel:
>                 if (unlikely(!inode_unhashed(old))) {
>                         iput(old);
>                         return -EBUSY;
>                 }
>                 iput(old);
> 
> it returns an error
> 
> with my patch:
>                if (isnew) {
>                         wait_on_new_inode(old);
>                         if (unlikely(!inode_unhashed(old))) {
>                                 iput(old);
>                                 return -EBUSY;
>                         }
>                 }
>                 iput(old);
> 
> unhashed status is only ever check if I_NEW was spotted,
> 
> which can be false. Afterwards the routine is stuck in endless cycle of
> finding the inode and iputting it.
> 
> Christian, I think the easiest way out is to add the fix I initially
> posted, inlined below. It *was* successfuly tested by syzbot. It retains
> inode_unhashed checks even when they are not necessary to avoid any more
> surprises.

Thanks for tracking this down. Now folded.