On 2026-04-01 12:03:09+0100, Mark Brown wrote:
> On Mon, Mar 30, 2026 at 11:15:00PM +0800, Chunyu Hu wrote:
>
> > The ksft_exit_fail_perror function previously only accepted a single string
> > argument, which limited its flexibility for providing specific context to
> > failure messages.
>
> > This change updates ksft_exit_fail_perror to support variable arguments,
> > similar to ksft_exit_fail_msg. Adding the __printf(1, 2) attribute enables
> > compile-time checking for format string correctness.
>
> This is causing build regressions on the arm64 selftests:
>
> /arm64/fp/za-fork-asm.o -o /build/stage/build-work/kselftest/arm64/fp/za-fork
> In file included from za-fork.c:12:
> ../../kselftest.h: In function ‘ksft_exit_fail_perror’:
> ../../kselftest.h:427:13: error: implicit declaration of function
> ‘vasprintf’; d
> id you mean ‘vsprintf’? [-Wimplicit-function-declaration]
> 427 | if (vasprintf(&buf, msg, args) == -1) {
> | ^~~~~~~~~
> | vsprintf
>
> This is because za-fork uses nolibc which does not implement
> vasprintf().
We can add vasprintf() to nolibc, I'll send a patch later today.
But it will be fairly inefficient, as our malloc() implementation
is *very* simple. Not that it would matter here.
That said, I am not a fan of the new ksft_exit_fail_perror().
What about this:
#define ksft_exit_fail_perror(msg, ...) \
ksft_exit_fail_msg(msg ": %s (%d)\n" __VA_OPT__(,) __VA_ARGS__,
strerror(errno), errno);
A similar treatment might be done to ksft_exit_fail_msg().
> I need to look at why this managed to pass the build testing I do in
> -next...
Thomas
