From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Heming Zhao <heming.zhao@suse.com>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH] ocfs2: restore -ERANGE check in ocfs2_xattr_tree_list_index_block()
Date: Tue, 22 Sep 2026 17:42:52 +0800 [thread overview]
Message-ID: <20260922094252.971631-1-joseph.qi@linux.alibaba.com> (raw)
ocfs2_xattr_list_entry() returns -ERANGE when the buffer handed in by
the caller is too small to hold the whole xattr name list. That is the
normal listxattr(2) protocol, userspace simply retries with a larger
buffer, so it is not an ocfs2 error and must not be logged as one.
Commit a46fa684fcb700 ("ocfs2: Don't printk the error when listing too
many xattrs.") already knew this and silenced two sites, quoting
(27738,0):ocfs2_iterate_xattr_buckets:3158 ERROR: status = -34
(27738,0):ocfs2_xattr_tree_list_index_block:3264 ERROR: status = -34
The refactoring in commit 47bca4950bc40f ("ocfs2: Abstract ocfs2 xattr
tree extend rec iteration process.") then rewrote
ocfs2_xattr_tree_list_index_block() around the new
ocfs2_iterate_xattr_index_block() helper and dropped that guard, so the
second message has been emitted ever since:
ocfs2_xattr_tree_list_index_block:4513 ERROR: status = -34
The exemption in ocfs2_iterate_xattr_buckets() survived because that
function was left alone, and the new helper does check for -ERANGE
itself, which is why only the outermost caller still logs it.
Restore the missing check. Only the log line changes: -ERANGE is still
returned to the VFS untouched, so listxattr(2) behaves exactly as
before.
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
---
fs/ocfs2/xattr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 25fb23cc00d2..590b8b63d684 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -4521,7 +4521,8 @@ static int ocfs2_xattr_tree_list_index_block(struct inode *inode,
ret = ocfs2_iterate_xattr_index_block(inode, blk_bh,
ocfs2_list_xattr_tree_rec, &xl);
if (ret) {
- mlog_errno(ret);
+ if (ret != -ERANGE)
+ mlog_errno(ret);
goto out;
}
--
2.39.3
reply other threads:[~2026-09-22 9:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260922094252.971631-1-joseph.qi@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
/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®