All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Wei Gao <wegao@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] splice06.c: Add splice check on proc files
Date: Wed, 30 Aug 2023 10:45:57 +0100	[thread overview]
Message-ID: <875y4wizri.fsf@suse.de> (raw)
In-Reply-To: <20230817003947.16029-1-wegao@suse.com>

Hello,

Subject had a typo s/splices/splice/.

Wei Gao via ltp <ltp@lists.linux.it> writes:

> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
>  testcases/kernel/syscalls/splice/splice06.c | 134 ++++++++++++++++++++
>  1 file changed, 134 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/splice/splice06.c
>
> diff --git a/testcases/kernel/syscalls/splice/splice06.c b/testcases/kernel/syscalls/splice/splice06.c
> new file mode 100644
> index 000000000..f14fd84c5
> --- /dev/null
> +++ b/testcases/kernel/syscalls/splice/splice06.c
> @@ -0,0 +1,134 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2023 SUSE LLC <wegao@suse.com>
> + */
> +
> +/*\
> + * [Description]
> + *
> + * This test is cover splice() on proc files.
> + *
> + */
> +
> +#define _GNU_SOURCE
> +
> +#include <stdio.h>
> +#include <errno.h>
> +#include <string.h>
> +#include <signal.h>
> +#include <sys/types.h>
> +#include <fcntl.h>
> +
> +#include "tst_test.h"
> +#include "lapi/splice.h"
> +
> +#define TEST_BLOCK_SIZE 100
> +#define NAME_SPACES_NUM 1024
> +#define PROCFILE "/proc/sys/user/max_user_namespaces"

This file is not available on a lot of configs. I'd suggest using
instead /proc/kernel/domainname which lets you read/write up to 64
bytes and is often not set. See kernel/utsname_sysctl.c

We should probably also test an integer based one like
/proc/sys/fs/pipe-max-size.

> +#define TESTFILE1 "splice_testfile_1"
> +#define TESTFILE2 "splice_testfile_2"

Why do we need these files? We should be able to write to a pipe then
splice it to the proc file(s). Splicing to/from a regular file is
handled in other tests.

Also splice from the proc file to a pipe then read the pipe.

> +
> +static int fd_in, fd_out;
> +static int origin_name_spaces_num;
> +static char line[TEST_BLOCK_SIZE];

Why are these global variables?

It's not because you make sure they are closed during cleanup.

> +
> +static void splice_file(void)
> +{
> +	int pipes[2];
> +	int ret;
> +
> +	SAFE_PIPE(pipes);
> +
> +	ret = splice(fd_in, NULL, pipes[1], NULL, TEST_BLOCK_SIZE, 0);
> +	if (ret < 0)
> +		tst_brk(TBROK | TERRNO, "splice(fd_in, pipe) failed");
> +
> +	ret = splice(pipes[0], NULL, fd_out, NULL, TEST_BLOCK_SIZE, 0);
> +	if (ret < 0)
> +		tst_brk(TBROK | TERRNO, "splice(pipe, fd_out) failed");
> +
> +	SAFE_CLOSE(fd_in);
> +	SAFE_CLOSE(fd_out);
> +	SAFE_CLOSE(pipes[0]);
> +	SAFE_CLOSE(pipes[1]);
> +}



> +
> +static void set_value(char file[], int num)
> +{
> +	int fd;
> +	int len = snprintf(NULL, 0, "%d", num);
> +
> +	memset(line, '\0', sizeof(line));
> +	sprintf(line, "%d", num);
> +
> +	fd = SAFE_OPEN(file, O_RDWR | O_CREAT | O_TRUNC, 0777);
> +	SAFE_WRITE(SAFE_WRITE_ALL, fd, line, len);
> +	SAFE_CLOSE(fd);

We have library functions to open then read, scan or write a
file. (SAFE_FILE_*).

> +}
> +
> +static int get_value(char file[])
> +{
> +	int fd, num, ret;
> +
> +	memset(line, '\0', sizeof(line));
> +
> +	fd = SAFE_OPEN(file, O_RDONLY);
> +	SAFE_READ(0, fd, line, TEST_BLOCK_SIZE);
> +	SAFE_CLOSE(fd);
> +
> +	ret = sscanf(line, "%d", &num);
> +	if (ret == EOF)
> +		tst_brk(TBROK | TERRNO, "sscanf error");
> +
> +	return num;
> +}
> +
> +static void splice_test(void)
> +{
> +
> +	int name_spaces_num_setting = get_value(PROCFILE);
> +
> +	fd_in = SAFE_OPEN(PROCFILE, O_RDONLY);
> +	fd_out = SAFE_OPEN(TESTFILE2, O_WRONLY | O_CREAT | O_TRUNC, 0666);
> +	splice_file();

The control flow is unecessarily hard to follow here. You are opening
fds in the outer scope then closing them inside splice_file().

Given that I don't think it is necessary to have TESTFILE1/2 I'll skip
the rest of the function. However you need to make the control flow or
data flow clearer.

> +
> +	if (name_spaces_num_setting == get_value(TESTFILE2))
> +		tst_res(TPASS, "Written data has been read back correctly");
> +	else
> +		tst_brk(TBROK | TERRNO, "Written data has been read back failed");
> +
> +	if (get_value(PROCFILE) != NAME_SPACES_NUM)
> +		name_spaces_num_setting = NAME_SPACES_NUM;
> +	else
> +		name_spaces_num_setting = NAME_SPACES_NUM + 1;
> +
> +	set_value(TESTFILE1, name_spaces_num_setting);
> +
> +	fd_in = SAFE_OPEN(TESTFILE1, O_RDONLY, 0777);
> +	fd_out = SAFE_OPEN(PROCFILE, O_WRONLY, 0777);
> +
> +	splice_file();
> +
> +	if (name_spaces_num_setting == get_value(PROCFILE))
> +		tst_res(TPASS, "Written data has been written correctly");
> +	else
> +		tst_brk(TBROK | TERRNO, "Written data has been written failed");
> +}
> +
> +static void setup(void)
> +{
> +	origin_name_spaces_num = get_value(PROCFILE);

We have a save and restore feature in tst_test (tst_test.save_restore).

> +}
> +
> +static void cleanup(void)
> +{
> +	set_value(PROCFILE, origin_name_spaces_num);
> +}
> +
> +static struct tst_test test = {
> +	.min_kver = "5.11",
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.test_all = splice_test,
> +	.needs_tmpdir = 1,
> +};
> -- 
> 2.35.3


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2023-08-30 10:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17  0:39 [LTP] [PATCH v1] splices06.c: Add splice check on proc files Wei Gao via ltp
2023-08-30  9:45 ` Richard Palethorpe [this message]
2023-09-02  3:03 ` [LTP] [PATCH v2] " Wei Gao via ltp
2023-09-04  8:01   ` Richard Palethorpe
2023-09-04  9:45   ` [LTP] [PATCH v3] " Wei Gao via ltp
2023-09-29 10:27     ` Richard Palethorpe

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=875y4wizri.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=ltp@lists.linux.it \
    --cc=wegao@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.