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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox