mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®