Re: [PATCH v5 1/5] selftests/mm: make file helpers return errors

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/16/26 14:32, Sarthak Sharma wrote:
> Change read_file(), write_file(), read_num() and write_num() in vm_util.c
> to report failures to callers instead of exiting from the helper.
> 
> Update the helpers to print TAP compatible diagnostics before returning
> errors and update their callers to handle those errors. This prepares
> the helpers to be moved to tools/lib/mm without carrying selftest-specific
> process-exit behaviour into the shared implementation.
> 
> Also, make read_file() return a negative errno on failure instead of 0, so
> callers can distinguish a successful read from an I/O error. Make
> read_num() reject negative and malformed values.
> 
> Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com>
> ---


[...]

>  
>  	fd = open(path, O_RDONLY);
> -	if (fd == -1)
> -		return 0;
> +	if (fd == -1) {
> +		int err = errno;
> +
> +		printf("# %s: %s (%d)\n", path, strerror(err), err);

Shouldn't we be using

ksft_print_msg()

That does the magic "# " for us.

[...]

> diff --git a/tools/testing/selftests/mm/vm_util.h b/tools/testing/selftests/mm/vm_util.h
> index ea8fc8fdf0eb..28c3d7c1faed 100644
> --- a/tools/testing/selftests/mm/vm_util.h
> +++ b/tools/testing/selftests/mm/vm_util.h
> @@ -164,10 +164,10 @@ int unpoison_memory(unsigned long pfn);
>  #define PAGEMAP_PRESENT(ent)	(((ent) & (1ull << 63)) != 0)
>  #define PAGEMAP_PFN(ent)	((ent) & ((1ull << 55) - 1))
>  
> -void write_file(const char *path, const char *buf, size_t buflen);
>  int read_file(const char *path, char *buf, size_t buflen);
> -unsigned long read_num(const char *path);
> -void write_num(const char *path, unsigned long num);
> +int write_file(const char *path, const char *buf, size_t buflen);
> +int read_num(const char *path, unsigned long *num);
> +int write_num(const char *path, unsigned long num);

In mm-unstable there is now write_num_ignore_einval(), where we want to ignore
-EINVAL and also not print any information.

Which makes me wonder whether we really need the diagnostic information, or if
we could just use return values that are clear enough when printing+failing in
the caller?

-- 
Cheers,

David