Re: [PATCH v7 4/7] selftests: ksft_exit_fail_perror: support printf style arguments

[Chunyu Hu <chuhu@redhat.com>]

On Wed, Apr 01, 2026 at 02:08:53PM +0200, Thomas Weißschuh wrote:
> 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.
Thanks! 
> 
> 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().

Thanks for the suggestion! I would use ksft_exit_fail_msg directly for
now, and we don't bother to make it that complex just for saving two
parameters.

> 
> > I need to look at why this managed to pass the build testing I do in
> > -next...
> 
> 
> Thomas
>