kselftest: futex: Fix memset with zero size warning

[PATCH] kselftest: futex: Fix memset with zero size warning

Posted by Wake Liu 2 months, 2 weeks ago

The `FIXTURE(args)` macro defines an empty `struct _test_data_args`,
leading to `sizeof(struct _test_data_args)` evaluating to 0. This
caused a build error due to a compiler warning on a `memset` call
with a zero size argument.

Adding a dummy member to the struct ensures its size is non-zero,
resolving the build issue.

Signed-off-by: Wake Liu <wakel@google.com>
---
 tools/testing/selftests/futex/functional/futex_requeue_pi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi.c b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
index f299d75848cd..000fec468835 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
@@ -52,6 +52,7 @@ struct thread_arg {
 
 FIXTURE(args)
 {
+	char dummy;
 };
 
 FIXTURE_SETUP(args)
-- 
2.52.0.rc1.455.g30608eb744-goog

Re: [PATCH] kselftest: futex: Fix memset with zero size warning

Posted by Thomas Gleixner 2 months, 2 weeks ago

On Wed, Nov 19 2025 at 11:00, Wake Liu wrote:
> The `FIXTURE(args)` macro defines an empty `struct _test_data_args`,
> leading to `sizeof(struct _test_data_args)` evaluating to 0. This
> caused a build error due to a compiler warning on a `memset` call
> with a zero size argument.

Where is that memset? The only possibly related one I can find in the
kselftest harness is:

        if (sizeof(foo) > 0)
           memset(foo, 0, sizeof(foo));

If your compiler complains about that, then you need to fix your
compiler and not perfectly correct code.

You again fail to provide enough information to understand what you are
trying to "fix" including the compiler version and related built
options.

Thanks,

        tglx

[PATCH] kselftest/harness: Use helper to avoid zero-size memset warning

Posted by Wake Liu 1 month, 2 weeks ago

When building kselftests with a toolchain that enables source
fortification (e.g., Android's build environment, which uses
-D_FORTIFY_SOURCE=3), a build failure occurs in tests that use an
empty FIXTURE().

The root cause is that an empty fixture struct results in
`sizeof(self_private)` evaluating to 0. The compiler's fortification
checks then detect the `memset()` call with a compile-time constant size
of 0, issuing a `-Wuser-defined-warnings` which is promoted to an error
by `-Werror`.

An initial attempt to guard the call with `if (sizeof(self_private) > 0)`
was insufficient. The compiler's static analysis is aggressive enough
to flag the `memset(..., 0)` pattern before evaluating the conditional,
thus still triggering the error.

To resolve this robustly, this change introduces a `static inline`
helper function, `__kselftest_memset_safe()`. This function wraps the
size check and the `memset()` call. By replacing the direct `memset()`
in the `__TEST_F_IMPL` macro with a call to this helper, we create an
abstraction boundary. This prevents the compiler's static analyzer from
"seeing" the problematic pattern at the macro expansion site, resolving
the build failure.

Build Context:
Compiler: Android (14488419, +pgo, +bolt, +lto, +mlgo, based on r584948) clang version 22.0.0 (https://android.googlesource.com/toolchain/llvm-project 2d65e4108033380e6fe8e08b1f1826cd2bfb0c99)
Relevant Options: -O2 -Wall -Werror -D_FORTIFY_SOURCE=3 -target i686-linux-android10000

Test: m kselftest_futex_futex_requeue_pi

Change-Id: If4fdfe6ffcbe9736fbd8f66b2453e8cbbb95e25e
Signed-off-by: Wake Liu <wakel@google.com>
---
 tools/testing/selftests/kselftest_harness.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
index 3f66e862e83eb..159cd6729af33 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -70,6 +70,12 @@
 
 #include "kselftest.h"
 
+static inline void __kselftest_memset_safe(void *s, int c, size_t n)
+{
+	if (n > 0)
+		memset(s, c, n);
+}
+
 #define TEST_TIMEOUT_DEFAULT 30
 
 /* Utilities exposed to the test definitions */
@@ -416,7 +422,7 @@
 				self = mmap(NULL, sizeof(*self), PROT_READ | PROT_WRITE, \
 					MAP_SHARED | MAP_ANONYMOUS, -1, 0); \
 			} else { \
-				memset(&self_private, 0, sizeof(self_private)); \
+				__kselftest_memset_safe(&self_private, 0, sizeof(self_private)); \
 				self = &self_private; \
 			} \
 		} \
-- 
2.52.0.351.gbe84eed79e-goog

Re: [PATCH] kselftest/harness: Use helper to avoid zero-size memset warning

Posted by Shuah Khan 1 month, 1 week ago

On 12/24/25 01:41, Wake Liu wrote:
> When building kselftests with a toolchain that enables source
> fortification (e.g., Android's build environment, which uses
> -D_FORTIFY_SOURCE=3), a build failure occurs in tests that use an
> empty FIXTURE().
> 
> The root cause is that an empty fixture struct results in
> `sizeof(self_private)` evaluating to 0. The compiler's fortification
> checks then detect the `memset()` call with a compile-time constant size
> of 0, issuing a `-Wuser-defined-warnings` which is promoted to an error
> by `-Werror`.
> 
> An initial attempt to guard the call with `if (sizeof(self_private) > 0)`
> was insufficient. The compiler's static analysis is aggressive enough
> to flag the `memset(..., 0)` pattern before evaluating the conditional,
> thus still triggering the error.
> 
> To resolve this robustly, this change introduces a `static inline`
> helper function, `__kselftest_memset_safe()`. This function wraps the
> size check and the `memset()` call. By replacing the direct `memset()`
> in the `__TEST_F_IMPL` macro with a call to this helper, we create an
> abstraction boundary. This prevents the compiler's static analyzer from
> "seeing" the problematic pattern at the macro expansion site, resolving
> the build failure.
> 
> Build Context:
> Compiler: Android (14488419, +pgo, +bolt, +lto, +mlgo, based on r584948) clang version 22.0.0 (https://android.googlesource.com/toolchain/llvm-project 2d65e4108033380e6fe8e08b1f1826cd2bfb0c99)
> Relevant Options: -O2 -Wall -Werror -D_FORTIFY_SOURCE=3 -target i686-linux-android10000
> 
> Test: m kselftest_futex_futex_requeue_pi
> 
> Change-Id: If4fdfe6ffcbe9736fbd8f66b2453e8cbbb95e25e

I removed this before applying. In the future remove these
before sending the patch - running checkpatch.pl prompts
you to remove it.

> Signed-off-by: Wake Liu <wakel@google.com>
> ---
>   tools/testing/selftests/kselftest_harness.h | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
> index 3f66e862e83eb..159cd6729af33 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -70,6 +70,12 @@
>   
>   #include "kselftest.h"
>   
> +static inline void __kselftest_memset_safe(void *s, int c, size_t n)
> +{
> +	if (n > 0)
> +		memset(s, c, n);
> +}
> +
>   #define TEST_TIMEOUT_DEFAULT 30
>   
>   /* Utilities exposed to the test definitions */
> @@ -416,7 +422,7 @@
>   				self = mmap(NULL, sizeof(*self), PROT_READ | PROT_WRITE, \
>   					MAP_SHARED | MAP_ANONYMOUS, -1, 0); \
>   			} else { \
> -				memset(&self_private, 0, sizeof(self_private)); \
> +				__kselftest_memset_safe(&self_private, 0, sizeof(self_private)); \
>   				self = &self_private; \
>   			} \
>   		} \


Applied to linux-kselftest fixes branch for next rc.

thanks,
-- Shuah

Re: [PATCH] kselftest: futex: Fix memset with zero size warning

Posted by André Almeida 2 months, 2 weeks ago

Hi Wake,

Em 19/11/2025 00:00, Wake Liu escreveu:
> The `FIXTURE(args)` macro defines an empty `struct _test_data_args`,
> leading to `sizeof(struct _test_data_args)` evaluating to 0. This
> caused a build error due to a compiler warning on a `memset` call
> with a zero size argument.
> 

Do you mind sharing your compiler options? I can't reproduce this 
warning here. I also noted that a few other selftests have this pattern 
of defining an empty FIXTURE(), do they also produce warnings?