linux-kernel - Re: [PATCH] fs: assert on ->i_count in iput

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7ck3szsab4zb3uzgh6aub5kmvm2slold5la2oyi264klwjel36@crjlqzwdmrgh>
Date: Wed, 1 Oct 2025 15:07:58 +0200
From: Jan Kara <jack@...e.cz>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Jan Kara <jack@...e.cz>, brauner@...nel.org, viro@...iv.linux.org.uk, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: assert on ->i_count in iput_final()

On Wed 01-10-25 14:12:13, Mateusz Guzik wrote:
> On Wed, Oct 1, 2025 at 2:07 PM Jan Kara <jack@...e.cz> wrote:
> > > diff --git a/fs/inode.c b/fs/inode.c
> > > index ec9339024ac3..fa82cb810af4 100644
> > > --- a/fs/inode.c
> > > +++ b/fs/inode.c
> > > @@ -1879,6 +1879,7 @@ static void iput_final(struct inode *inode)
> > >       int drop;
> > >
> > >       WARN_ON(inode->i_state & I_NEW);
> > > +     VFS_BUG_ON_INODE(atomic_read(&inode->i_count) != 0, inode);
> >
> > This seems pointless given when iput_final() is called...
> >
> 
> This and the other check explicitly "wrap" the ->drop_inode call.

I understand but given iput() has just decremented i_count to 0 before
calling iput_final() this beginning of the "wrap" looks pretty pointless to
me.

> > >       if (op->drop_inode)
> > >               drop = op->drop_inode(inode);
> > > @@ -1893,6 +1894,12 @@ static void iput_final(struct inode *inode)
> > >               return;
> > >       }
> > >
> > > +     /*
> > > +      * Re-check ->i_count in case the ->drop_inode() hooks played games.
> > > +      * Note we only execute this if the verdict was to drop the inode.
> > > +      */
> > > +     VFS_BUG_ON_INODE(atomic_read(&inode->i_count) != 0, inode);
> > > +
> >
> > I'm not sure this can catch much but OK...
> >
> 
> It can catch drop routines which bumped the ref but did not release
> it, or which indicated to continue with drop while someone else
> snatched the reference.

Right. 

> Preferaby the APIs would prevent that in the first place, but there is
> quite a bit of shit-shoveling before that happens.

Agreed.

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR