diff mbox series

[v2,2/2] selftests/nolibc: add testcase for pipe

Message ID 9221753abe0509ef5cbb474a31873012e0e40706.1690733545.git.tanyuan@tinylab.org
State New
Headers
Series tools/nolibc: add pipe(), pipe2() and their testcase |

Commit Message

Yuan Tan July 31, 2023, 5:51 a.m. UTC 
  Add a testcase of pipe that child process sends message to parent
process.

Here we use memcmp() to avoid the output buffer issue.

Suggested-by: Thomas Weißschuh <thomas@t-8ch.de>
Suggested-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/all/c5de2d13-3752-4e1b-90d9-f58cca99c702@t-8ch.de/
Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
---
 tools/testing/selftests/nolibc/nolibc-test.c | 35 ++++++++++++++++++++
 1 file changed, 35 insertions(+)

Comments

Thomas Weißschuh July 31, 2023, 6:10 a.m. UTC | #1 
On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> Add a testcase of pipe that child process sends message to parent
> process.

Thinking about it some more:

What's the advantage of going via a child process?
The pipe should work the same within the same process.

> Here we use memcmp() to avoid the output buffer issue.

This sentence is meaningless without the background from v1.
You can drop it.

> Suggested-by: Thomas Weißschuh <thomas@t-8ch.de>
> Suggested-by: Willy Tarreau <w@1wt.eu>
> Link: https://lore.kernel.org/all/c5de2d13-3752-4e1b-90d9-f58cca99c702@t-8ch.de/
> Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
> ---
>  tools/testing/selftests/nolibc/nolibc-test.c | 35 ++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> index 03b1d30f5507..2653ab8d5124 100644
> --- a/tools/testing/selftests/nolibc/nolibc-test.c
> +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> @@ -767,6 +767,41 @@ int test_mmap_munmap(void)
>  	return ret;
>  }
>  
> +int test_pipe(void)

Should be static and actually get called :-)

> +{
> +	const char *const msg = "hello, nolibc";
> +	int pipefd[2];
> +	char buf[32];
> +	pid_t pid;
> +	ssize_t len;
> +
> +	if (pipe(pipefd) == -1)
> +		return 1;
> +
> +	pid = fork();
> +
> +	switch (pid) {
> +	case -1:
> +		return 1;
> +
> +	case 0:
> +		close(pipefd[0]);
> +		write(pipefd[1], msg, strlen(msg));
> +		close(pipefd[1]);
> +		exit(EXIT_SUCCESS);
> +
> +	default:
> +		close(pipefd[1]);
> +		len = read(pipefd[0], buf, sizeof(buf));
> +		close(pipefd[0]);
> +		waitpid(pid, NULL, 0);
> +
> +		if (len != strlen(msg))
> +			return 1;
> +		return !!memcmp(buf, msg, len);
> +	}
> +}
> +
>  
>  /* Run syscall tests between IDs <min> and <max>.
>   * Return 0 on success, non-zero on failure.
> -- 
> 2.34.1
>
Yuan Tan July 31, 2023, 12:35 p.m. UTC | #2 
Hi Thomas,

On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > Add a testcase of pipe that child process sends message to parent
> > process.
> 
> Thinking about it some more:
> 
> What's the advantage of going via a child process?
> The pipe should work the same within the same process.
> 

The pipe is commonly used for process communication, and I think as a
test case it is supposed to cover the most common scenarios.

> > Here we use memcmp() to avoid the output buffer issue.
> 
> This sentence is meaningless without the background from v1.
> You can drop it.
> 

Got it.

> > Suggested-by: Thomas Weißschuh <thomas@t-8ch.de>
> > Suggested-by: Willy Tarreau <w@1wt.eu>
> > Link: https://lore.kernel.org/all/c5de2d13-3752-4e1b-90d9-f58cca99c702@t-8ch.de/
> > Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
> > ---
> >  tools/testing/selftests/nolibc/nolibc-test.c | 35 ++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> > index 03b1d30f5507..2653ab8d5124 100644
> > --- a/tools/testing/selftests/nolibc/nolibc-test.c
> > +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> > @@ -767,6 +767,41 @@ int test_mmap_munmap(void)
> >         return ret;
> >  }
> >  
> > +int test_pipe(void)
> 
> Should be static and actually get called :-)
> 
> > +{
> > +       const char *const msg = "hello, nolibc";
> > +       int pipefd[2];
> > +       char buf[32];
> > +       pid_t pid;
> > +       ssize_t len;
> > +
> > +       if (pipe(pipefd) == -1)
> > +               return 1;
> > +
> > +       pid = fork();
> > +
> > +       switch (pid) {
> > +       case -1:
> > +               return 1;
> > +
> > +       case 0:
> > +               close(pipefd[0]);
> > +               write(pipefd[1], msg, strlen(msg));
> > +               close(pipefd[1]);
> > +               exit(EXIT_SUCCESS);
> > +
> > +       default:
> > +               close(pipefd[1]);
> > +               len = read(pipefd[0], buf, sizeof(buf));
> > +               close(pipefd[0]);
> > +               waitpid(pid, NULL, 0);
> > +
> > +               if (len != strlen(msg))
> > +                       return 1;
> > +               return !!memcmp(buf, msg, len);
> > +       }
> > +}
> > +
> >  
> >  /* Run syscall tests between IDs <min> and <max>.
> >   * Return 0 on success, non-zero on failure.
> > -- 
> > 2.34.1
> > 
>
Thomas Weißschuh July 31, 2023, 3:41 p.m. UTC | #3 
On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > Add a testcase of pipe that child process sends message to parent
> > > process.
> > 
> > Thinking about it some more:
> > 
> > What's the advantage of going via a child process?
> > The pipe should work the same within the same process.
> > 
> 
> The pipe is commonly used for process communication, and I think as a
> test case it is supposed to cover the most common scenarios.

The testcase is supposed to cover the code of nolibc.
It should be the *minimal* amount of code to be reasonable sure that the
code in nolibc does the correct thing.
If pipe() returns a value that behaves like a pipe I see no reason to
doubt it will also survive fork().

Validating that would mean testing the kernel and not nolibc.
For the kernel there are different testsuites.

Less code means less work for everyone involved, now and in the future.
Yuan Tan July 31, 2023, 6:01 p.m. UTC | #4 
Hi Thomas,
On Mon, 2023-07-31 at 17:41 +0200, Thomas Weißschuh wrote:
> On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> > On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > > Add a testcase of pipe that child process sends message to
> > > > parent
> > > > process.
> > > 
> > > Thinking about it some more:
> > > 
> > > What's the advantage of going via a child process?
> > > The pipe should work the same within the same process.
> > > 
> > 
> > The pipe is commonly used for process communication, and I think as
> > a
> > test case it is supposed to cover the most common scenarios.
> 
> The testcase is supposed to cover the code of nolibc.
> It should be the *minimal* amount of code to be reasonable sure that
> the
> code in nolibc does the correct thing.
> If pipe() returns a value that behaves like a pipe I see no reason to
> doubt it will also survive fork().
> 
> Validating that would mean testing the kernel and not nolibc.
> For the kernel there are different testsuites.
> 
> Less code means less work for everyone involved, now and in the
> future.
> 

It's a good point and I never thought about this aspect.

I wonder whether the code below is enough?

static int test_pipe(void)
{
	int pipefd[2];

	if (pipe(pipefd) == -1)
		return 1;

	close(pipefd[0]);
	close(pipefd[1]);

	return 0;
}

And I forgot to add this line:

	CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break;

I will add it in next patch.
Thomas Weißschuh July 31, 2023, 6:28 p.m. UTC | #5 
On 2023-08-01 02:01:36+0800, Yuan Tan wrote:
> Hi Thomas,
> On Mon, 2023-07-31 at 17:41 +0200, Thomas Weißschuh wrote:
> > On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> > > On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > > > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > > > Add a testcase of pipe that child process sends message to
> > > > > parent
> > > > > process.
> > > > 
> > > > Thinking about it some more:
> > > > 
> > > > What's the advantage of going via a child process?
> > > > The pipe should work the same within the same process.
> > > > 
> > > 
> > > The pipe is commonly used for process communication, and I think as
> > > a
> > > test case it is supposed to cover the most common scenarios.
> > 
> > The testcase is supposed to cover the code of nolibc.
> > It should be the *minimal* amount of code to be reasonable sure that
> > the
> > code in nolibc does the correct thing.
> > If pipe() returns a value that behaves like a pipe I see no reason to
> > doubt it will also survive fork().
> > 
> > Validating that would mean testing the kernel and not nolibc.
> > For the kernel there are different testsuites.
> > 
> > Less code means less work for everyone involved, now and in the
> > future.
> > 
> 
> It's a good point and I never thought about this aspect.
> 
> I wonder whether the code below is enough?
> 
> static int test_pipe(void)
> {
> 	int pipefd[2];
> 
> 	if (pipe(pipefd) == -1)
> 		return 1;
> 
> 	close(pipefd[0]);
> 	close(pipefd[1]);
> 
> 	return 0;
> }

That is very barebones.

If accidentally a wrong syscall number was used and the used syscall
would not take any arguments this test would still succeed.

Keeping the write-read-cycle from the previous revision would test that
nicely. Essentially the same code as before but without the fork().

> 
> And I forgot to add this line:
> 
> 	CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break;
> 
> I will add it in next patch.
>
Yuan Tan Aug. 1, 2023, 6:51 a.m. UTC | #6 
Hi Thomas,

On Mon, 2023-07-31 at 20:28 +0200, Thomas Weißschuh wrote:
> On 2023-08-01 02:01:36+0800, Yuan Tan wrote:
> > Hi Thomas,
> > On Mon, 2023-07-31 at 17:41 +0200, Thomas Weißschuh wrote:
> > > On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> > > > On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > > > > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > > > > Add a testcase of pipe that child process sends message to
> > > > > > parent
> > > > > > process.
> > > > > 
> > > > > Thinking about it some more:
> > > > > 
> > > > > What's the advantage of going via a child process?
> > > > > The pipe should work the same within the same process.
> > > > > 
> > > > 
> > > > The pipe is commonly used for process communication, and I
> > > > think as
> > > > a
> > > > test case it is supposed to cover the most common scenarios.
> > > 
> > > The testcase is supposed to cover the code of nolibc.
> > > It should be the *minimal* amount of code to be reasonable sure
> > > that
> > > the
> > > code in nolibc does the correct thing.
> > > If pipe() returns a value that behaves like a pipe I see no
> > > reason to
> > > doubt it will also survive fork().
> > > 
> > > Validating that would mean testing the kernel and not nolibc.
> > > For the kernel there are different testsuites.
> > > 
> > > Less code means less work for everyone involved, now and in the
> > > future.
> > > 
> > 
> > It's a good point and I never thought about this aspect.
> > 
> > I wonder whether the code below is enough?
> > 
> > static int test_pipe(void)
> > {
> >         int pipefd[2];
> > 
> >         if (pipe(pipefd) == -1)
> >                 return 1;
> > 
> >         close(pipefd[0]);
> >         close(pipefd[1]);
> > 
> >         return 0;
> > }
> 
> That is very barebones.
> 
> If accidentally a wrong syscall number was used and the used syscall
> would not take any arguments this test would still succeed.
> 
> Keeping the write-read-cycle from the previous revision would test
> that
> nicely. Essentially the same code as before but without the fork().
> 
> > 
> > And I forgot to add this line:
> > 
> >         CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break;
> > 
> > I will add it in next patch.
> > 
> 

In the situation you described, that is indeed the case.

Would this be fine?

static int test_pipe(void)
{
	const char *const msg = "hello, nolibc";
	int pipefd[2];
	char buf[32];
	ssize_t len;

	if (pipe(pipefd) == -1)
		return 1;

	write(pipefd[1], msg, strlen(msg));
	close(pipefd[1]);
	len = read(pipefd[0], buf, sizeof(buf));
	close(pipefd[0]);

	if (len != strlen(msg))
		return 1;

	return !!memcmp(buf, msg, len);
}
Thomas Weißschuh Aug. 1, 2023, 7:20 a.m. UTC | #7 
On 2023-08-01 14:51:40+0800, Yuan Tan wrote:
> Hi Thomas,
> 
> On Mon, 2023-07-31 at 20:28 +0200, Thomas Weißschuh wrote:
> > On 2023-08-01 02:01:36+0800, Yuan Tan wrote:
> > > Hi Thomas,
> > > On Mon, 2023-07-31 at 17:41 +0200, Thomas Weißschuh wrote:
> > > > On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> > > > > On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > > > > > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > > > > > Add a testcase of pipe that child process sends message to
> > > > > > > parent
> > > > > > > process.
> > > > > > 
> > > > > > Thinking about it some more:
> > > > > > 
> > > > > > What's the advantage of going via a child process?
> > > > > > The pipe should work the same within the same process.
> > > > > > 
> > > > > 
> > > > > The pipe is commonly used for process communication, and I
> > > > > think as
> > > > > a
> > > > > test case it is supposed to cover the most common scenarios.
> > > > 
> > > > The testcase is supposed to cover the code of nolibc.
> > > > It should be the *minimal* amount of code to be reasonable sure
> > > > that
> > > > the
> > > > code in nolibc does the correct thing.
> > > > If pipe() returns a value that behaves like a pipe I see no
> > > > reason to
> > > > doubt it will also survive fork().
> > > > 
> > > > Validating that would mean testing the kernel and not nolibc.
> > > > For the kernel there are different testsuites.
> > > > 
> > > > Less code means less work for everyone involved, now and in the
> > > > future.
> > > > 
> > > 
> > > It's a good point and I never thought about this aspect.
> > > 
> > > I wonder whether the code below is enough?
> > > 
> > > static int test_pipe(void)
> > > {
> > >         int pipefd[2];
> > > 
> > >         if (pipe(pipefd) == -1)
> > >                 return 1;
> > > 
> > >         close(pipefd[0]);
> > >         close(pipefd[1]);
> > > 
> > >         return 0;
> > > }
> > 
> > That is very barebones.
> > 
> > If accidentally a wrong syscall number was used and the used syscall
> > would not take any arguments this test would still succeed.
> > 
> > Keeping the write-read-cycle from the previous revision would test
> > that
> > nicely. Essentially the same code as before but without the fork().
> > 
> > > 
> > > And I forgot to add this line:
> > > 
> > >         CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break;
> > > 
> > > I will add it in next patch.
> > > 
> > 
> 
> In the situation you described, that is indeed the case.
> 
> Would this be fine?
> 
> static int test_pipe(void)
> {
> 	const char *const msg = "hello, nolibc";
> 	int pipefd[2];
> 	char buf[32];
> 	ssize_t len;
> 
> 	if (pipe(pipefd) == -1)
> 		return 1;
> 
> 	write(pipefd[1], msg, strlen(msg));
> 	close(pipefd[1]);
> 	len = read(pipefd[0], buf, sizeof(buf));
> 	close(pipefd[0]);
> 
> 	if (len != strlen(msg))
> 		return 1;
> 
> 	return !!memcmp(buf, msg, len);
> }

Looks good!

The return value of write() could also be validated but given we
validate the return value from read() it shouldn't make a difference.

(Also the manual manipulation of "buf" is gone that necessitated the
check in v1 of the series)
Yuan Tan Aug. 1, 2023, 12:23 p.m. UTC | #8 
Hi Thomas,

On Tue, 2023-08-01 at 09:20 +0200, Thomas Weißschuh wrote:
> On 2023-08-01 14:51:40+0800, Yuan Tan wrote:
> > Hi Thomas,
> > 
> > On Mon, 2023-07-31 at 20:28 +0200, Thomas Weißschuh wrote:
> > > On 2023-08-01 02:01:36+0800, Yuan Tan wrote:
> > > > Hi Thomas,
> > > > On Mon, 2023-07-31 at 17:41 +0200, Thomas Weißschuh wrote:
> > > > > On 2023-07-31 20:35:28+0800, Yuan Tan wrote:
> > > > > > On Mon, 2023-07-31 at 08:10 +0200, Thomas Weißschuh wrote:
> > > > > > > On 2023-07-31 13:51:00+0800, Yuan Tan wrote:
> > > > > > > > Add a testcase of pipe that child process sends message
> > > > > > > > to
> > > > > > > > parent
> > > > > > > > process.
> > > > > > > 
> > > > > > > Thinking about it some more:
> > > > > > > 
> > > > > > > What's the advantage of going via a child process?
> > > > > > > The pipe should work the same within the same process.
> > > > > > > 
> > > > > > 
> > > > > > The pipe is commonly used for process communication, and I
> > > > > > think as
> > > > > > a
> > > > > > test case it is supposed to cover the most common
> > > > > > scenarios.
> > > > > 
> > > > > The testcase is supposed to cover the code of nolibc.
> > > > > It should be the *minimal* amount of code to be reasonable
> > > > > sure
> > > > > that
> > > > > the
> > > > > code in nolibc does the correct thing.
> > > > > If pipe() returns a value that behaves like a pipe I see no
> > > > > reason to
> > > > > doubt it will also survive fork().
> > > > > 
> > > > > Validating that would mean testing the kernel and not nolibc.
> > > > > For the kernel there are different testsuites.
> > > > > 
> > > > > Less code means less work for everyone involved, now and in
> > > > > the
> > > > > future.
> > > > > 
> > > > 
> > > > It's a good point and I never thought about this aspect.
> > > > 
> > > > I wonder whether the code below is enough?
> > > > 
> > > > static int test_pipe(void)
> > > > {
> > > >         int pipefd[2];
> > > > 
> > > >         if (pipe(pipefd) == -1)
> > > >                 return 1;
> > > > 
> > > >         close(pipefd[0]);
> > > >         close(pipefd[1]);
> > > > 
> > > >         return 0;
> > > > }
> > > 
> > > That is very barebones.
> > > 
> > > If accidentally a wrong syscall number was used and the used
> > > syscall
> > > would not take any arguments this test would still succeed.
> > > 
> > > Keeping the write-read-cycle from the previous revision would
> > > test
> > > that
> > > nicely. Essentially the same code as before but without the
> > > fork().
> > > 
> > > > 
> > > > And I forgot to add this line:
> > > > 
> > > >         CASE_TEST(pipe); EXPECT_SYSZR(1, test_pipe()); break;
> > > > 
> > > > I will add it in next patch.
> > > > 
> > > 
> > 
> > In the situation you described, that is indeed the case.
> > 
> > Would this be fine?
> > 
> > static int test_pipe(void)
> > {
> >         const char *const msg = "hello, nolibc";
> >         int pipefd[2];
> >         char buf[32];
> >         ssize_t len;
> > 
> >         if (pipe(pipefd) == -1)
> >                 return 1;
> > 
> >         write(pipefd[1], msg, strlen(msg));
> >         close(pipefd[1]);
> >         len = read(pipefd[0], buf, sizeof(buf));
> >         close(pipefd[0]);
> > 
> >         if (len != strlen(msg))
> >                 return 1;
> > 
> >         return !!memcmp(buf, msg, len);
> > }
> 
> Looks good!
> 
> The return value of write() could also be validated but given we
> validate the return value from read() it shouldn't make a difference.
> 
> (Also the manual manipulation of "buf" is gone that necessitated the
> check in v1 of the series)
> 

I am sorry that I didn't catch your last sentence.

Did you mean this piece of code does not need any further modifications
right?
Thomas Weißschuh Aug. 1, 2023, 2:46 p.m. UTC | #9 
Aug 1, 2023 14:23:22 Yuan Tan <tanyuan@tinylab.org>:

>>> Would this be fine?
>>>
>>> static int test_pipe(void)
>>> {
>>>         const char *const msg = "hello, nolibc";
>>>         int pipefd[2];
>>>         char buf[32];
>>>         ssize_t len;
>>>
>>>         if (pipe(pipefd) == -1)
>>>                 return 1;
>>>
>>>         write(pipefd[1], msg, strlen(msg));
>>>         close(pipefd[1]);
>>>         len = read(pipefd[0], buf, sizeof(buf));
>>>         close(pipefd[0]);
>>>
>>>         if (len != strlen(msg))
>>>                 return 1;
>>>
>>>         return !!memcmp(buf, msg, len);
>>> }
>>
>> Looks good!
>>
>> The return value of write() could also be validated but given we
>> validate the return value from read() it shouldn't make a difference.
>>
>> (Also the manual manipulation of "buf" is gone that necessitated the
>> check in v1 of the series)
>>
>
> I am sorry that I didn't catch your last sentence.
>
> Did you mean this piece of code does not need any further modifications
> right?

Yes, for me this is great!
Sorry for being unclear.
diff mbox series

Patch

diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 03b1d30f5507..2653ab8d5124 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -767,6 +767,41 @@  int test_mmap_munmap(void)
 	return ret;
 }
 
+int test_pipe(void)
+{
+	const char *const msg = "hello, nolibc";
+	int pipefd[2];
+	char buf[32];
+	pid_t pid;
+	ssize_t len;
+
+	if (pipe(pipefd) == -1)
+		return 1;
+
+	pid = fork();
+
+	switch (pid) {
+	case -1:
+		return 1;
+
+	case 0:
+		close(pipefd[0]);
+		write(pipefd[1], msg, strlen(msg));
+		close(pipefd[1]);
+		exit(EXIT_SUCCESS);
+
+	default:
+		close(pipefd[1]);
+		len = read(pipefd[0], buf, sizeof(buf));
+		close(pipefd[0]);
+		waitpid(pid, NULL, 0);
+
+		if (len != strlen(msg))
+			return 1;
+		return !!memcmp(buf, msg, len);
+	}
+}
+
 
 /* Run syscall tests between IDs <min> and <max>.
  * Return 0 on success, non-zero on failure.