From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "leocstone@gmail.com" <leocstone@gmail.com>,
"jack@suse.cz" <jack@suse.cz>,
"penguin-kernel@I-love.SAKURA.ne.jp"
<penguin-kernel@I-love.SAKURA.ne.jp>,
"willy@infradead.org" <willy@infradead.org>,
"brauner@kernel.org" <brauner@kernel.org>
Cc: "glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
"frank.li@vivo.com" <frank.li@vivo.com>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: RE: [PATCH v4] hfs: update sanity check of the root record
Date: Fri, 1 Aug 2025 18:26:31 +0000 [thread overview]
Message-ID: <06bea1c3fc9080b5798e6b5ad1ad533a145bf036.camel@ibm.com> (raw)
In-Reply-To: <5f0769cd-2cbb-4349-8be4-dfdc74c2c5f8@I-love.SAKURA.ne.jp>
On Fri, 2025-08-01 at 06:12 +0900, Tetsuo Handa wrote:
> On 2025/08/01 3:03, Viacheslav Dubeyko wrote:
> > On Thu, 2025-07-31 at 07:02 +0900, Tetsuo Handa wrote:
> > > On 2025/07/31 4:24, Viacheslav Dubeyko wrote:
> > > > If we considering case HFS_CDR_DIR in hfs_read_inode(), then we know that it
> > > > could be HFS_POR_CNID, HFS_ROOT_CNID, or >= HFS_FIRSTUSER_CNID. Do you mean that
> > > > HFS_POR_CNID could be a problem in hfs_write_inode()?
> > >
> > > Yes. Passing one of 1, 5 or 15 instead of 2 from hfs_fill_super() triggers BUG()
> > > in hfs_write_inode(). We *MUST* validate at hfs_fill_super(), or hfs_read_inode()
> > > shall have to also reject 1, 5 and 15 (and as a result only accept 2).
> >
> > The fix should be in hfs_read_inode(). Currently, suggested solution hides the
> > issue but not fix the problem.
>
> Not fixing this problem might be hiding other issues, by hitting BUG() before
> other issues shows up.
>
I am not going to start a philosophical discussion. We simply need to fix the
bug. The suggested patch doesn't fix the issue.
> > Because b-tree nodes could contain multiple
> > corrupted records. Now, this patch checks only record for root folder. Let's
> > imagine that root folder record will be OK but another record(s) will be
> > corrupted in such way.
>
> Can the inode number of the record retrieved as a result of
> hfs_cat_find_brec(HFS_ROOT_CNID) be something other than HFS_ROOT_CNID ?
>
> If the inode number of the record retrieved as a result of
> hfs_cat_find_brec(HFS_ROOT_CNID) must be HFS_ROOT_CNID, this patch itself will be
> a complete fix for this problem.
>
You are working with corrupted volume. In this case, you can extract any state
of the Catalog File's record.
> > Finally, we will have successful mount but operation with
> > corrupted record(s) will trigger this issue. So, I cannot consider this patch as
> > a complete fix of the problem.
>
> Did you try what you think as a fix of this problem (I guess something like
> shown below will be needed for avoid hitting BUG()) using
> https://lkml.kernel.org/r/a8f8da77-f099-499b-98e0-39ed159b6a2d@I-love.SAKURA.ne.jp ?
>
If you believe that you have another version of the patch, then simply send it
and I will review it. Sorry, I haven't enough time to discuss every movement of
your thoughts.
> diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
> index a81ce7a740b9..d60395111ed5 100644
> --- a/fs/hfs/inode.c
> +++ b/fs/hfs/inode.c
> @@ -81,7 +81,8 @@ static bool hfs_release_folio(struct folio *folio, gfp_t mask)
> tree = HFS_SB(sb)->cat_tree;
> break;
> default:
> - BUG();
> + pr_err("detected unknown inode %lu, running fsck.hfs is recommended.\n",
> + inode->i_ino);
> return false;
> }
>
> @@ -305,11 +306,31 @@ static int hfs_test_inode(struct inode *inode, void *data)
> case HFS_CDR_FIL:
> return inode->i_ino == be32_to_cpu(rec->file.FlNum);
> default:
> - BUG();
> + pr_err("detected unknown type %u, running fsck.hfs is recommended.\n", rec->type);
> return 1;
> }
> }
>
> +static bool is_bad_id(unsigned long ino)
> +{
> + switch (ino) {
> + case 0:
> + case 3:
> + case 4:
> + case 6:
> + case 7:
> + case 8:
> + case 9:
> + case 10:
> + case 11:
> + case 12:
> + case 13:
> + case 14:
> + return true;
> + }
> + return false;
> +}
Please, don't use hardcoded value. I already shared the point that we must use
the declared constants.
This function is incorrect and it cannot work for folders and files at the same
time.
Thanks,
Slava.
> +
> /*
> * hfs_read_inode
> */
> @@ -348,6 +369,10 @@ static int hfs_read_inode(struct inode *inode, void *data)
> }
>
> inode->i_ino = be32_to_cpu(rec->file.FlNum);
> + if (is_bad_id(inode->i_ino)) {
> + make_bad_inode(inode);
> + break;
> + }
> inode->i_mode = S_IRUGO | S_IXUGO;
> if (!(rec->file.Flags & HFS_FIL_LOCK))
> inode->i_mode |= S_IWUGO;
> @@ -358,9 +383,15 @@ static int hfs_read_inode(struct inode *inode, void *data)
> inode->i_op = &hfs_file_inode_operations;
> inode->i_fop = &hfs_file_operations;
> inode->i_mapping->a_ops = &hfs_aops;
> + if (inode->i_ino < 16)
> + pr_info("HFS_CDR_FIL i_ino=%ld\n", inode->i_ino);
> break;
> case HFS_CDR_DIR:
> inode->i_ino = be32_to_cpu(rec->dir.DirID);
> + if (is_bad_id(inode->i_ino)) {
> + make_bad_inode(inode);
> + break;
> + }
> inode->i_size = be16_to_cpu(rec->dir.Val) + 2;
> HFS_I(inode)->fs_blocks = 0;
> inode->i_mode = S_IFDIR | (S_IRWXUGO & ~hsb->s_dir_umask);
> @@ -368,6 +399,8 @@ static int hfs_read_inode(struct inode *inode, void *data)
> inode_set_atime_to_ts(inode, inode_set_ctime_to_ts(inode, hfs_m_to_utime(rec->dir.MdDat))));
> inode->i_op = &hfs_dir_inode_operations;
> inode->i_fop = &hfs_dir_operations;
> + if (inode->i_ino < 16)
> + pr_info("HFS_CDR_DIR i_ino=%ld\n", inode->i_ino);
> break;
> default:
> make_bad_inode(inode);
> @@ -441,7 +474,8 @@ int hfs_write_inode(struct inode *inode, struct writeback_control *wbc)
> hfs_btree_write(HFS_SB(inode->i_sb)->cat_tree);
> return 0;
> default:
> - BUG();
> + pr_err("detected unknown inode %lu, running fsck.hfs is recommended.\n",
> + inode->i_ino);
> return -EIO;
> }
> }
>
>
> # for i in $(seq 0 15); do timeout 1 unshare -m ./hfs $i; done
> # dmesg | grep fsck
> [ 52.563547] [ T479] hfs: detected unknown inode 1, running fsck.hfs is recommended.
> [ 56.606238] [ T255] hfs: detected unknown inode 5, running fsck.hfs is recommended.
> [ 66.694795] [ T500] hfs: detected unknown inode 15, running fsck.hfs is recommended.
next prev parent reply other threads:[~2025-08-01 18:26 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-23 13:32 [PATCH] hfs: don't use BUG() when we can continue Tetsuo Handa
2024-12-05 13:45 ` [PATCH (REPOST)] " Tetsuo Handa
2024-12-05 13:59 ` Matthew Wilcox
2024-12-05 14:14 ` Tetsuo Handa
2025-06-25 5:03 ` Tetsuo Handa
2025-07-15 6:51 ` [PATCH v2] hfs: remove BUG() from hfs_release_folio()/hfs_test_inode()/hfs_write_inode() Tetsuo Handa
2025-07-15 19:20 ` Viacheslav Dubeyko
2025-07-17 15:30 ` Tetsuo Handa
2025-07-17 15:32 ` [PATCH v3] " Tetsuo Handa
2025-07-17 18:25 ` Viacheslav Dubeyko
2025-07-17 19:35 ` Matthew Wilcox
2025-07-17 19:49 ` Viacheslav Dubeyko
2025-07-17 22:08 ` Tetsuo Handa
2025-07-21 17:04 ` Viacheslav Dubeyko
2025-07-22 10:42 ` Tetsuo Handa
2025-07-22 13:30 ` Matthew Wilcox
2025-07-22 14:04 ` Tetsuo Handa
2025-07-22 14:22 ` Matthew Wilcox
2025-07-22 18:08 ` Viacheslav Dubeyko
2025-07-23 1:07 ` Tetsuo Handa
2025-07-23 2:16 ` Tetsuo Handa
2025-07-23 18:19 ` Viacheslav Dubeyko
2025-07-23 18:43 ` Viacheslav Dubeyko
2025-07-24 6:55 ` Tetsuo Handa
2025-07-24 19:49 ` Viacheslav Dubeyko
2025-07-24 22:05 ` Tetsuo Handa
2025-07-24 23:20 ` Tetsuo Handa
2025-07-25 4:16 ` Tetsuo Handa
2025-07-25 17:47 ` Viacheslav Dubeyko
2025-07-25 21:52 ` Tetsuo Handa
2025-07-28 19:37 ` Viacheslav Dubeyko
2025-07-28 21:38 ` Tetsuo Handa
2025-07-29 23:21 ` [PATCH v4] hfs: update sanity check of the root record Tetsuo Handa
2025-07-30 19:24 ` Viacheslav Dubeyko
2025-07-30 22:02 ` Tetsuo Handa
2025-07-31 18:03 ` Viacheslav Dubeyko
2025-07-31 21:12 ` Tetsuo Handa
2025-08-01 18:26 ` Viacheslav Dubeyko [this message]
2025-08-01 21:52 ` Tetsuo Handa
2025-08-04 22:00 ` Viacheslav Dubeyko
2025-08-21 10:57 ` Tetsuo Handa
2025-07-25 17:45 ` [PATCH v3] hfs: remove BUG() from hfs_release_folio()/hfs_test_inode()/hfs_write_inode() Viacheslav Dubeyko
2025-07-25 22:25 ` Tetsuo Handa
2025-07-27 13:27 ` Tetsuo Handa
2025-07-25 17:42 ` Viacheslav Dubeyko
2025-07-25 22:22 ` Tetsuo Handa
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=06bea1c3fc9080b5798e6b5ad1ad533a145bf036.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jack@suse.cz \
--cc=leocstone@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=slava@dubeyko.com \
--cc=willy@infradead.org \
/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).