From: Shardul Bankar <shardul.b@mpiricsoftware.com>
To: slava@dubeyko.com, glaubitz@physik.fu-berlin.de, frank.li@vivo.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
janak@mpiric.us, kalpan.jani@mpiricsoftware.com,
shardulsb08@gmail.com,
Shardul Bankar <shardul.b@mpiricsoftware.com>
Subject: [PATCH] hfsplus: fix hfs_bnode_split() failure on sparsely-filled nodes
Date: Fri, 24 Apr 2026 03:19:36 +0530 [thread overview]
Message-ID: <20260423214936.444718-1-shardul.b@mpiricsoftware.com> (raw)
hfs_bnode_split() determines the split point by scanning the node's
offset table for the first record whose data offset exceeds a threshold
derived from node_size / 2. When all record data fits within the first
half of the node, no record offset exceeds the threshold, the loop
exhausts all records, and the function returns -ENOSPC even though the
node can be validly split. This causes xattr insertions to fail
silently.
The failing code path is exercised by xfstests generic/070 and
generic/642 during xattr stress operations.
Fix this by re-scanning with a threshold based on the actual data
midpoint when the position-based scan exhausts. If the re-scan also
exhausts, fall back to splitting off the last record.
Reported-by: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
fs/hfsplus/brec.c | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/fs/hfsplus/brec.c b/fs/hfsplus/brec.c
index e3df89284079..cfc909c808a4 100644
--- a/fs/hfsplus/brec.c
+++ b/fs/hfsplus/brec.c
@@ -282,12 +282,32 @@ static struct hfs_bnode *hfs_bnode_split(struct hfs_find_data *fd)
old_rec_off -= rec_size;
if (++num_recs < node->num_recs)
continue;
- hfs_bnode_put(node);
- hfs_bnode_unlink(new_node);
- hfs_bnode_put(new_node);
- if (next_node)
- hfs_bnode_put(next_node);
- return ERR_PTR(-ENOSPC);
+ /*
+ * All data fits within the node_size/2 threshold,
+ * so re-scan using the actual data midpoint.
+ */
+ size = hfs_bnode_read_u16(node, tree->node_size -
+ (node->num_recs + 1) * rec_size);
+ size = ((int)node_desc_size + size) / 2;
+ old_rec_off = tree->node_size - (2 * rec_size);
+ num_recs = 1;
+ for (;;) {
+ data_start = hfs_bnode_read_u16(node,
+ old_rec_off);
+ if (data_start > size)
+ break;
+ old_rec_off -= rec_size;
+ if (++num_recs < node->num_recs)
+ continue;
+ /* last record holds most of the data */
+ num_recs = node->num_recs - 1;
+ old_rec_off = tree->node_size -
+ (num_recs + 1) * rec_size;
+ data_start = hfs_bnode_read_u16(node,
+ old_rec_off);
+ break;
+ }
+ break;
}
if (fd->record + 1 < num_recs) {
--
2.34.1
next reply other threads:[~2026-04-23 21:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 21:49 Shardul Bankar [this message]
2026-04-24 20:06 ` 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=20260423214936.444718-1-shardul.b@mpiricsoftware.com \
--to=shardul.b@mpiricsoftware.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=janak@mpiric.us \
--cc=kalpan.jani@mpiricsoftware.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shardulsb08@gmail.com \
--cc=slava@dubeyko.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®