From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "contact@gvernon.com" <contact@gvernon.com>
Cc: "frank.li@vivo.com" <frank.li@vivo.com>,
"linux-kernel-mentees@lists.linux.dev"
<linux-kernel-mentees@lists.linux.dev>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"penguin-kernel@i-love.sakura.ne.jp"
<penguin-kernel@i-love.sakura.ne.jp>,
"syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com"
<syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com>,
"glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: RE: [PATCH v2 1/2] hfs: Validate CNIDs in hfs_read_inode
Date: Tue, 25 Nov 2025 19:15:48 +0000 [thread overview]
Message-ID: <be86c750a1cd2ddcd3968237995f1e5162eb381e.camel@ibm.com> (raw)
In-Reply-To: <aSTuaUFnXzoQeIpv@Bertha>
On Mon, 2025-11-24 at 23:46 +0000, George Anthony Vernon wrote:
> On Tue, Nov 11, 2025 at 10:42:09PM +0000, Viacheslav Dubeyko wrote:
> > On Tue, 2025-11-11 at 23:39 +0900, Tetsuo Handa wrote:
> > > On 2025/11/04 10:47, George Anthony Vernon wrote:
> > > > + if (!is_valid_cnid(inode->i_ino,
> > > > + S_ISDIR(inode->i_mode) ? HFS_CDR_DIR : HFS_CDR_FIL))
> > > > + BUG();
> > >
> > > Is it guaranteed that hfs_write_inode() and make_bad_inode() never run in parallel?
> > > If no, this check is racy because make_bad_inode() makes S_ISDIR(inode->i_mode) == false.
> > >
> >
> > Any inode should be completely created before any hfs_write_inode() call can
> > happen. So, I don't see how hfs_write_inode() and make_bad_inode() could run in
> > parallel.
> >
>
> Could we not read the same inode a second time, during the execution of
> hfs_write_inode()?
>
> Then I believe we could hit make_bad_inode() in hfs_read_inode() once we
> had already entered hfs_write_inode(), and so test a cnid against the
> wrong i_mode.
>
>
Maybe, I am missing something in your point. But your explanation sounds
slightly strange to me.
At first, VFS code tries to find inode object in the cache of already created
inodes. So, if we created inode, then it should be in inode cache. It means that
we don't need to execute any read operations for such inode object. So, we can
call hfs_write_inode() only if inode object completely created and it is in
inode cache.
Potentially, it is possible to imagine situation that two or more threads try to
access the same inode ID in parallel while inode object is not created yet. But,
usually, newly created inode is locked until the end of creation operation. So,
only one thread will call hfs_read_inode() and others will get inode object from
the cache.
So, hfs_write_inode() could happen if we took the inode from inode cache. And
this inode could be good or bad object. But I still don't see how
hfs_read_inode() and hfs_write_inode() can be called in parallel for the same
inode object.
Thanks,
Slava.
next prev parent reply other threads:[~2025-11-25 19:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 2:45 [PATCH] hfs: Validate CNIDs in hfs_read_inode George Anthony Vernon
2025-10-03 22:40 ` Viacheslav Dubeyko
2025-10-04 1:25 ` George Anthony Vernon
2025-10-07 13:40 ` Viacheslav Dubeyko
2025-10-09 12:57 ` Tetsuo Handa
2025-10-29 3:20 ` George Anthony Vernon
2025-10-29 10:06 ` Tetsuo Handa
2025-11-04 1:47 ` [PATCH v2 0/2] hfs: Validate CNIDs read from filesystem George Anthony Vernon
2025-11-04 1:47 ` [PATCH v2 1/2] hfs: Validate CNIDs in hfs_read_inode George Anthony Vernon
2025-11-04 22:34 ` Viacheslav Dubeyko
2025-11-11 0:00 ` George Anthony Vernon
2025-11-11 0:48 ` Viacheslav Dubeyko
2025-11-24 22:33 ` George Anthony Vernon
2025-11-25 19:02 ` Viacheslav Dubeyko
2025-11-11 14:39 ` Tetsuo Handa
2025-11-11 22:42 ` Viacheslav Dubeyko
2025-11-24 23:46 ` George Anthony Vernon
2025-11-25 19:15 ` Viacheslav Dubeyko [this message]
2025-11-30 10:07 ` Tetsuo Handa
2025-11-04 1:47 ` [PATCH v2 2/2] hfs: Update sanity check of the root record George Anthony Vernon
2025-11-04 23:01 ` Viacheslav Dubeyko
2025-11-10 23:03 ` George Anthony Vernon
2025-11-10 23:34 ` Viacheslav Dubeyko
2025-11-11 0:23 ` George Anthony Vernon
2025-11-11 0:34 ` Viacheslav Dubeyko
2025-11-24 22:56 ` George Anthony Vernon
2025-11-11 14:26 ` Tetsuo Handa
2025-11-11 22:56 ` Viacheslav Dubeyko
2025-11-14 14:18 ` Tetsuo Handa
2025-11-14 21:00 ` Viacheslav Dubeyko
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=be86c750a1cd2ddcd3968237995f1e5162eb381e.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=contact@gvernon.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=skhan@linuxfoundation.org \
--cc=slava@dubeyko.com \
--cc=syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com \
/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).