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

Christian Brauner
2025-11-25T09:35:24Z

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.