From: 陈华昭(Lyican) <lyican53@gmail.com>
To: ceph-devel@vger.kernel.org
Cc: idryomov@gmail.com, xiubli@redhat.com,
linux-kernel@vger.kernel.org, Slava.Dubeyko@ibm.com
Subject: [PATCH] ceph: Fix potential undefined behavior in crush_ln() with GCC 11.1.0
Date: Thu, 18 Sep 2025 09:50:52 +0800 [thread overview]
Message-ID: <1AD55673-B7F4-4DB7-AE80-1AC81709F65A@gmail.com> (raw)
When compiled with GCC 11.1.0 and -march=x86-64-v3 -O1 optimization flags,
__builtin_clz() may generate BSR instructions without proper zero handling.
The BSR instruction has undefined behavior when the source operand is zero,
which could occur when (x & 0x1FFFF) equals 0 in the crush_ln() function.
This issue is documented in GCC bug 101175:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101175
The problematic code path occurs in crush_ln() when:
- x is incremented from xin
- (x & 0x18000) == 0 (condition for the optimization)
- (x & 0x1FFFF) == 0 (zero argument to __builtin_clz)
Testing with GCC 11.5.0 confirms that specific input values like 0x7FFFF,
0x9FFFF, 0xBFFFF, 0xDFFFF, 0xFFFFF can trigger this condition, causing
__builtin_clz(0) to be called with undefined behavior.
Add a zero check before calling __builtin_clz() to ensure defined behavior
across all GCC versions and optimization levels.
Signed-off-by: Huazhao Chen <lyican53@gmail.com>
---
net/ceph/crush/mapper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ceph/crush/mapper.c b/net/ceph/crush/mapper.c
index 1234567..abcdef0 100644
--- a/net/ceph/crush/mapper.c
+++ b/net/ceph/crush/mapper.c
@@ -262,7 +262,8 @@ static __u64 crush_ln(unsigned int xin)
* do it in one step instead of iteratively
*/
if (!(x & 0x18000)) {
- int bits = __builtin_clz(x & 0x1FFFF) - 16;
+ u32 masked = x & 0x1FFFF;
+ int bits = masked ? __builtin_clz(masked) - 16 : 16;
x <<= bits;
iexpon = 15 - bits;
}
--
2.40.1
Testing:
=======
The issue can be verified with the following test case that identifies
problematic input values:
```c
#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
/* Simplified version showing the problematic pattern */
static void test_crush_ln_bug(void)
{
unsigned int problematic_inputs[] = {
0x7FFFF, 0x9FFFF, 0xBFFFF, 0xDFFFF, 0xFFFFF
};
printf("Testing inputs that trigger __builtin_clz(0):\n");
for (int i = 0; i < 5; i++) {
unsigned int input = problematic_inputs[i];
unsigned int x = input + 1;
if (!(x & 0x18000)) {
unsigned int masked = x & 0x1FFFF;
printf("Input 0x%06X: x+1=0x%06X, masked=0x%05X %s\n",
input, x, masked,
masked == 0 ? "- BUG! Zero to __builtin_clz" : "- Safe");
}
}
}
```
This test confirms that all five input values result in __builtin_clz(0)
being called, demonstrating the need for the zero check in the fix.
The fix ensures that when masked == 0, we use the appropriate default value
(16) instead of calling __builtin_clz(0), maintaining the same mathematical
behavior while avoiding undefined compiler behavior.
next reply other threads:[~2025-09-18 1:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 1:50 陈华昭(Lyican) [this message]
2025-09-18 2:09 ` Viacheslav Dubeyko
2025-09-18 18:07 ` Viacheslav Dubeyko
2025-09-19 2:34 ` 陈华昭(Lyican)
2025-09-19 18:51 ` Viacheslav Dubeyko
2025-09-20 12:06 ` 陈华昭(Lyican)
2025-09-22 17:19 ` Viacheslav Dubeyko
2025-09-24 1:27 ` 陈华昭(Lyican)
2025-09-26 23:42 陈华昭
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=1AD55673-B7F4-4DB7-AE80-1AC81709F65A@gmail.com \
--to=lyican53@gmail.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xiubli@redhat.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®