From: Mateusz Guzik <mjguzik@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: brauner@kernel.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: assert on ->i_count in iput_final()
Date: Wed, 1 Oct 2025 14:12:13 +0200 [thread overview]
Message-ID: <CAGudoHHZL0g9=eRqjUOS2sez8Mew7r1TRWaR+uX-7YuYomd3WA@mail.gmail.com> (raw)
In-Reply-To: <zvd5obgxrkbqeifnuvvvhhjeh7t4cveziipwoii3hjaztxytpa@qlcxp4l2r5jg>
On Wed, Oct 1, 2025 at 2:07 PM Jan Kara <jack@suse.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.
> > 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.
Preferaby the APIs would prevent that in the first place, but there is
quite a bit of shit-shoveling before that happens.
next prev parent reply other threads:[~2025-10-01 12:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 1:00 [PATCH] fs: assert on ->i_count in iput_final() Mateusz Guzik
2025-10-01 12:06 ` Jan Kara
2025-10-01 12:12 ` Mateusz Guzik [this message]
2025-10-01 13:07 ` Jan Kara
2025-10-01 14:28 ` Mateusz Guzik
2025-10-01 15:11 ` Jan Kara
2025-10-06 11:36 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGudoHHZL0g9=eRqjUOS2sez8Mew7r1TRWaR+uX-7YuYomd3WA@mail.gmail.com' \
--to=mjguzik@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).