From: Shardul Bankar <shardul.b@mpiricsoftware.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>,
"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>
Cc: "janak@mpiric.us" <janak@mpiric.us>,
"janak@mpiricsoftware.com" <janak@mpiricsoftware.com>,
"syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com"
<syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com>,
shardulsb08@gmail.com
Subject: Re: [PATCH v6 2/2] hfsplus: validate b-tree node 0 bitmap at mount time
Date: Wed, 18 Mar 2026 11:39:40 +0530 [thread overview]
Message-ID: <462cd1c4f31f6cc2d7077d076f4b07eed185e57a.camel@mpiricsoftware.com> (raw)
In-Reply-To: <c4df4e9ea51ac7cf02ece60e258b19cdcd628b7e.camel@ibm.com>
On Mon, 2026-03-16 at 22:35 +0000, Viacheslav Dubeyko wrote:
> On Sun, 2026-03-15 at 22:50 +0530, Shardul Bankar wrote:
> >
> > +/**
> > + * hfs_bmap_test_bit - test a bit in the b-tree map
> > + * @node: the b-tree node containing the map record
> > + * @node_bit_idx: the relative bit index within the node's map
> > record
> > + *
> > + * Returns 1 if set, 0 if clear, or a negative error code on
> > failure.
> > + */
> > +static int hfs_bmap_test_bit(struct hfs_bnode *node, u32
> > node_bit_idx)
>
> Why not return bool data type?
>
> > +{
> > + struct hfs_bmap_ctx ctx;
> > + struct page *page;
> > + u8 *bmap, byte, mask;
> > +
> > + page = hfs_bmap_get_map_page(node, &ctx, node_bit_idx /
> > BITS_PER_BYTE);
> > + if (IS_ERR(page))
> > + return PTR_ERR(page);
>
> We can return false for the case of error.
>
> > +
> > + bmap = kmap_local_page(page);
> > + byte = bmap[ctx.off];
> > + kunmap_local(bmap);
> > +
> > + mask = 1 << (7 - (node_bit_idx % BITS_PER_BYTE));
> > + return (byte & mask) ? 1 : 0;
>
> This is why I would like to see bool data type. :)
>
I completely agree. Changing the return type to `bool` and returning
`false` on both an IO error and a cleared bit vastly simplifies the
caller. I will update `hfs_bmap_test_bit()` to return a `bool`, and I
will collapse the two `res < 0` and `res == 0` validation checks in
`hfs_btree_open()` into a single `if (!hfs_bmap_test_bit(node, 0))`
block in v7.
> > +}
> > +
> > +
> > /**
> > * hfs_bmap_clear_bit - clear a bit in the b-tree map
> > * @node: the b-tree node containing the map record
> > @@ -218,15 +244,36 @@ static int hfs_bmap_clear_bit(struct
> > hfs_bnode *node, u32 node_bit_idx)
> > return 0;
> > }
> >
> > +#define HFS_EXTENT_TREE_NAME "Extents"
>
> Maybe we need to have Extents Overflow File (or B-tree), Catalog
> file,
> Attributes file?
>
Good point, those are the proper structural names. For v7, I will
update the macros to "Extents Overflow File", "Catalog File", and
"Attributes File", and I will slightly tweak the `pr_warn` format
string to accommodate the new names gracefully.
> > +#define HFS_CATALOG_TREE_NAME "Catalog"
> > +#define HFS_ATTR_TREE_NAME "Attributes"
> > +#define HFS_UNKNOWN_TREE_NAME "Unknown"
> > +
> > +static const char *hfs_btree_name(u32 cnid)
> > +{
> > + switch (cnid) {
> > + case HFSPLUS_EXT_CNID:
> > + return HFS_EXTENT_TREE_NAME;
> > + case HFSPLUS_CAT_CNID:
> > + return HFS_CATALOG_TREE_NAME;
> > + case HFSPLUS_ATTR_CNID:
> > + return HFS_ATTR_TREE_NAME;
> > + default:
> > + return HFS_UNKNOWN_TREE_NAME;
> > + }
> > +}
> > +
> > /* Get a reference to a B*Tree and do some initial checks */
> > struct hfs_btree *hfs_btree_open(struct super_block *sb, u32 id)
> > {
> > struct hfs_btree *tree;
> > struct hfs_btree_header_rec *head;
> > struct address_space *mapping;
> > + struct hfs_bnode *node;
> > struct inode *inode;
> > struct page *page;
> > unsigned int size;
> > + int res;
> >
> > tree = kzalloc_obj(*tree);
> > if (!tree)
> > @@ -331,6 +378,26 @@ struct hfs_btree *hfs_btree_open(struct
> > super_block *sb, u32 id)
> >
> > kunmap_local(head);
> > put_page(page);
> > +
> > + node = hfs_bnode_find(tree, HFSPLUS_TREE_HEAD);
> > + if (IS_ERR(node))
> > + goto free_inode;
> > +
> > + res = hfs_bmap_test_bit(node, 0);
>
> We definitely can return false for both cases.
>
Ack'ed
I will prepare the v7 patchset with these final stylistic polishings.
Thanks for the guidance throughout this series!
Shardul
next prev parent reply other threads:[~2026-03-18 6:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-15 17:20 [PATCH v6 0/2] hfsplus: prevent b-tree allocator corruption Shardul Bankar
2026-03-15 17:20 ` [PATCH v6 1/2] hfsplus: refactor b-tree map page access and add node-type validation Shardul Bankar
2026-03-16 22:21 ` Viacheslav Dubeyko
2026-03-18 6:08 ` Shardul Bankar
2026-03-15 17:20 ` [PATCH v6 2/2] hfsplus: validate b-tree node 0 bitmap at mount time Shardul Bankar
2026-03-16 22:35 ` Viacheslav Dubeyko
2026-03-18 6:09 ` Shardul Bankar [this message]
2026-03-16 22:36 ` [PATCH v6 0/2] hfsplus: prevent b-tree allocator corruption 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=462cd1c4f31f6cc2d7077d076f4b07eed185e57a.camel@mpiricsoftware.com \
--to=shardul.b@mpiricsoftware.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=janak@mpiric.us \
--cc=janak@mpiricsoftware.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shardulsb08@gmail.com \
--cc=slava@dubeyko.com \
--cc=syzbot+1c8ff72d0cd8a50dfeaa@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
all inboxes | Powered by JetHome®