linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tigran Aivazian <aivazian.tigran@gmail.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: LKML <linux-kernel@vger.kernel.org>,
	 linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] bfs: Verify inode mode when loading from disk
Date: Sun, 12 Oct 2025 18:02:30 +0100	[thread overview]
Message-ID: <CAK+_RLmwT5EHC6aajJxG0_ccPe7YhnWkd_wOPhhCz3mGo8Ub_g@mail.gmail.com> (raw)
In-Reply-To: <ddd2cd94-683f-462b-a475-cc04462e9bdd@I-love.SAKURA.ne.jp>

On Sun, 12 Oct 2025 at 08:35, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Well, I feel that we should choose "replace the 0x0000FFFF mask with
> 0x00000FFF" approach, for situation might be worse than HFS+ case.
> ...
> -       inode->i_mode = 0x0000FFFF & le32_to_cpu(di->i_mode);
> +       /*
> +        * https://martin.hinner.info/fs/bfs/bfs-structure.html explains that
> +        * BFS in SCO UnixWare environment used only lower 9 bits of di->i_mode
> +        * value. This means that, although bfs_write_inode() saves whole
> +        * inode->i_mode bits (which include S_IFMT bits and S_IS{UID,GID,VTX}
> +        * bits), middle 7 bits of di->i_mode value can be garbage when these
> +        * bits were not saved by bfs_write_inode().
> +        * Since we can't tell whether middle 7 bits are garbage, use only
> +        * lower 12 bits (i.e. tolerate S_IS{UID,GID,VTX} bits possibly being
> +        * garbage) and reconstruct S_IFMT bits for Linux environment from
> +        * di->i_vtype value.
> +        */
> +       inode->i_mode = 0x00000FFF & le32_to_cpu(di->i_mode);
>         if (le32_to_cpu(di->i_vtype) == BFS_VDIR) {
>                 inode->i_mode |= S_IFDIR;
>                 inode->i_op = &bfs_dir_inops;
> @@ -71,6 +83,11 @@ struct inode *bfs_iget(struct super_block *sb, unsigned long ino)
>                 inode->i_op = &bfs_file_inops;
>                 inode->i_fop = &bfs_file_operations;
>                 inode->i_mapping->a_ops = &bfs_aops;
> +       } else {
> +               brelse(bh);
> +               printf("Unknown vtype=%u %s:%08lx\n",
> +                      le32_to_cpu(di->i_vtype), inode->i_sb->s_id, ino);
> +               goto error;
>         }

Agreed -- given that historical BFS may leave those "middle 7 bits"
uninitialised, we shouldn't trust any S_IFMT coming off disk. Masking
to the lower 12 bits and reconstructing type from vtype is the right
thing to do.

Two optional tiny nits for readability:

  * use a symbolic mask for the 12 bits we keep:
        inode->i_mode = le32_to_cpu(di->i_mode) &
                (S_IRWXU | S_IRWXG | S_IRWXO | S_ISUID | S_ISGID | S_ISVTX);

  * cache the endianness conversions:
        u32 dmode = le32_to_cpu(di->i_mode);
        u32 dvtype = le32_to_cpu(di->i_vtype);
        inode->i_mode = dmode & (S_IRWXU | S_IRWXG | S_IRWXO |
                                 S_ISUID | S_ISGID | S_ISVTX);
        if (dvtype == BFS_VDIR) { ... } else if (dvtype == BFS_VREG) { ... }
        else {
                brelse(bh);
                printf("Unknown vtype=%u mode=0%07o %s:%08lx\n",
                       dvtype, dmode, inode->i_sb->s_id, ino);
                goto error;
        }

With or without those nits, your approach looks good to me.

Reviewed-by: Tigran Aivazian <aivazian.tigran@gmail.com>

  reply	other threads:[~2025-10-12 17:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10 14:24 [PATCH] bfs: Verify inode mode when loading from disk Tetsuo Handa
2025-10-10 15:44 ` Tigran Aivazian
2025-10-10 16:06   ` Tigran Aivazian
2025-10-10 23:19     ` Tetsuo Handa
2025-10-11 16:29       ` Tigran Aivazian
2025-10-12  7:34         ` Tetsuo Handa
2025-10-12 17:02           ` Tigran Aivazian [this message]
2025-10-13  5:44             ` [PATCH v2] bfs: Reconstruct file type " 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=CAK+_RLmwT5EHC6aajJxG0_ccPe7YhnWkd_wOPhhCz3mGo8Ub_g@mail.gmail.com \
    --to=aivazian.tigran@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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).