From: Youling Tang <youling.tang@linux.dev>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: linux-bcachefs@vger.kernel.org, linux-kernel@vger.kernel.org,
youling.tang@linux.dev, Youling Tang <tangyouling@kylinos.cn>
Subject: [PATCH 2/3] bcachefs: Fix maximum link count check when creating hard links
Date: Fri, 26 Sep 2025 10:21:49 +0800 [thread overview]
Message-ID: <20250926022150.493115-3-youling.tang@linux.dev> (raw)
In-Reply-To: <20250926022150.493115-1-youling.tang@linux.dev>
From: Youling Tang <tangyouling@kylinos.cn>
When I changed the maximum link count U32_MAX to 4 for testing purposes, I
discovered that for regular files, the maximum number of hard links created
could actually reach 5 (`inode->i_nlink`).
This occurs because `bi->bi_nlink` does not represent the actual `inode->i_nlink`
value, but rather equals `inode->i_nlink - nlink_bias(bi->bi_mode)`. Therefore,
the `bi->bi_nlink` check in bch2_inode_nlink_inc() needs to be corrected.
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
---
NOTE: If pathconf is to be added to support _PC_LINK_MAX for bcachefs in
libc later, BCH_LINK_MAX can be defined as ((1U << 31) - 1U) like xfs.
fs/bcachefs/bcachefs.h | 1 +
fs/bcachefs/inode.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/bcachefs/bcachefs.h b/fs/bcachefs/bcachefs.h
index ddfacad0f70c..9d5e6866b1b6 100644
--- a/fs/bcachefs/bcachefs.h
+++ b/fs/bcachefs/bcachefs.h
@@ -714,6 +714,7 @@ struct btree_debug {
unsigned id;
};
+#define BCH_LINK_MAX U32_MAX
#define BCH_TRANSACTIONS_NR 128
struct btree_transaction_stats {
diff --git a/fs/bcachefs/inode.c b/fs/bcachefs/inode.c
index 5765144b4d65..eedffb505517 100644
--- a/fs/bcachefs/inode.c
+++ b/fs/bcachefs/inode.c
@@ -1192,7 +1192,7 @@ int bch2_inode_nlink_inc(struct bch_inode_unpacked *bi)
if (bi->bi_flags & BCH_INODE_unlinked)
bi->bi_flags &= ~BCH_INODE_unlinked;
else {
- if (bi->bi_nlink == U32_MAX)
+ if (bi->bi_nlink == BCH_LINK_MAX - nlink_bias(bi->bi_mode))
return -BCH_ERR_too_many_links;
bi->bi_nlink++;
--
2.43.0
next prev parent reply other threads:[~2025-09-26 2:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 2:21 [PATCH 0/3] bcachefs: Fix some hard link count issues Youling Tang
2025-09-26 2:21 ` [PATCH 1/3] bcachefs: return -EMLINK instead of -EINVAL when hard link count exceeds limit Youling Tang
2025-09-26 2:21 ` Youling Tang [this message]
2025-09-26 2:21 ` [PATCH 3/3] bcachefs: Move the link counting check to the VFS layer Youling Tang
2025-09-26 3:42 ` Kent Overstreet
2025-09-26 4:22 ` Youling Tang
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=20250926022150.493115-3-youling.tang@linux.dev \
--to=youling.tang@linux.dev \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tangyouling@kylinos.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.