[PATCH v2 0/2] tools/nolibc: add pipe(), pipe2() and their testcase

[PATCH v2 0/2] tools/nolibc: add pipe(), pipe2() and their testcase

[Yuan Tan]

Hi, Willy, Thomas,

Thanks to your advice and I really learned a lot from it.

V2 now uses pipe2() to wrap pipe(), and fixes the strcmp issue in test
case.

Best regards,
Yuan Tan

Yuan Tan (2):
  tools/nolibc: add pipe() and pipe2() support
  selftests/nolibc: add testcase for pipe

 tools/include/nolibc/sys.h                   | 24 ++++++++++++++
 tools/testing/selftests/nolibc/nolibc-test.c | 35 ++++++++++++++++++++
 2 files changed, 59 insertions(+)

-- 
2.34.1

[PATCH v2 1/2] tools/nolibc: add pipe() and pipe2() support

[Yuan Tan]

According to manual page [1], posix spec [2] and source code like
arch/mips/kernel/syscall.c, for historic reasons, the sys_pipe() syscall
on some architectures has an unusual calling convention.  It returns
results in two registers which means there is no need for it to do
verify the validity of a userspace pointer argument.  Historically that
used to be expensive in Linux.  These days the performance advantage is
negligible.

Nolibc doesn't support the unusual calling convention above, luckily
Linux provides a generic sys_pipe2() with an additional flags argument
from 2.6.27. If flags is 0, then pipe2() is the same as pipe(). So here
we use sys_pipe2() to implement the pipe().

pipe2() is also provided to allow users to use flags argument on demand.

[1]: https://man7.org/linux/man-pages/man2/pipe.2.html
[2]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/pipe.html

Suggested-by: Zhangjin Wu <falcon@tinylab.org>
Link: https://lore.kernel.org/all/20230729100401.GA4577@1wt.eu/
Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
---
 tools/include/nolibc/sys.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/include/nolibc/sys.h b/tools/include/nolibc/sys.h
index 8bfe7db20b80..9fec09c22dbe 100644
--- a/tools/include/nolibc/sys.h
+++ b/tools/include/nolibc/sys.h
@@ -752,6 +752,30 @@ int open(const char *path, int flags, ...)
 }
 
 
+/*
+ * int pipe2(int pipefd[2], int flags);
+ * int pipe(int pipefd[2]);
+ */
+
+static __attribute__((unused))
+int sys_pipe2(int pipefd[2], int flags)
+{
+	return my_syscall2(__NR_pipe, pipefd, flags);
+}
+
+static __attribute__((unused))
+int pipe2(int pipefd[2], int flags)
+{
+	return __sysret(sys_pipe2(pipefd, flags));
+}
+
+static __attribute__((unused))
+int pipe(int pipefd[2])
+{
+	pipe2(pipefd, 0);
+}
+
+
 /*
  * int prctl(int option, unsigned long arg2, unsigned long arg3,
  *                       unsigned long arg4, unsigned long arg5);
-- 
2.34.1

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

[Yuan Tan]

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(+)

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.
-- 
2.34.1

Re: [PATCH v2 1/2] tools/nolibc: add pipe() and pipe2() support

[Thomas Weißschuh]

On 2023-07-31 13:50:45+0800, Yuan Tan wrote:
> According to manual page [1], posix spec [2] and source code like
> arch/mips/kernel/syscall.c, for historic reasons, the sys_pipe() syscall
> on some architectures has an unusual calling convention.  It returns
> results in two registers which means there is no need for it to do
> verify the validity of a userspace pointer argument.  Historically that
> used to be expensive in Linux.  These days the performance advantage is
> negligible.
> 
> Nolibc doesn't support the unusual calling convention above, luckily
> Linux provides a generic sys_pipe2() with an additional flags argument
> from 2.6.27. If flags is 0, then pipe2() is the same as pipe(). So here
> we use sys_pipe2() to implement the pipe().
> 
> pipe2() is also provided to allow users to use flags argument on demand.
> 
> [1]: https://man7.org/linux/man-pages/man2/pipe.2.html
> [2]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/pipe.html
> 
> Suggested-by: Zhangjin Wu <falcon@tinylab.org>
> Link: https://lore.kernel.org/all/20230729100401.GA4577@1wt.eu/
> Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
> ---
>  tools/include/nolibc/sys.h | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/tools/include/nolibc/sys.h b/tools/include/nolibc/sys.h
> index 8bfe7db20b80..9fec09c22dbe 100644
> --- a/tools/include/nolibc/sys.h
> +++ b/tools/include/nolibc/sys.h
> @@ -752,6 +752,30 @@ int open(const char *path, int flags, ...)
>  }
>  
>  
> +/*
> + * int pipe2(int pipefd[2], int flags);
> + * int pipe(int pipefd[2]);
> + */
> +
> +static __attribute__((unused))
> +int sys_pipe2(int pipefd[2], int flags)
> +{
> +	return my_syscall2(__NR_pipe, pipefd, flags);
> +}

Should be __NR_pipe2.

> +static __attribute__((unused))
> +int pipe2(int pipefd[2], int flags)
> +{
> +	return __sysret(sys_pipe2(pipefd, flags));
> +}
> +
> +static __attribute__((unused))
> +int pipe(int pipefd[2])
> +{
> +	pipe2(pipefd, 0);
> +}
> +
> +
>  /*
>   * int prctl(int option, unsigned long arg2, unsigned long arg3,
>   *                       unsigned long arg4, unsigned long arg5);
> -- 
> 2.34.1
> 

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

[Thomas Weißschuh]

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
> 

Re: [PATCH v2 0/2] tools/nolibc: add pipe(), pipe2() and their testcase

[Thomas Weißschuh]

Hi Yuan!

On 2023-07-31 13:50:31+0800, Yuan Tan wrote:
> Thanks to your advice and I really learned a lot from it.
> 
> V2 now uses pipe2() to wrap pipe(), and fixes the strcmp issue in test
> case.

Thanks!

I have some more comments for the patches.

For new revisions you should also link to the old revision.

> Best regards,
> Yuan Tan
> 
> Yuan Tan (2):
>   tools/nolibc: add pipe() and pipe2() support
>   selftests/nolibc: add testcase for pipe
> 
>  tools/include/nolibc/sys.h                   | 24 ++++++++++++++
>  tools/testing/selftests/nolibc/nolibc-test.c | 35 ++++++++++++++++++++
>  2 files changed, 59 insertions(+)
> 
> -- 
> 2.34.1
> 

Re: [PATCH v2 1/2] tools/nolibc: add pipe() and pipe2() support

[Thomas Weißschuh]

On 2023-07-31 13:50:45+0800, Yuan Tan wrote:
> [..]

> +static __attribute__((unused))
> +int pipe(int pipefd[2])
> +{
> +	pipe2(pipefd, 0);

This is missing a "return".

> +}
> +
> +
>  /*
>   * int prctl(int option, unsigned long arg2, unsigned long arg3,
>   *                       unsigned long arg4, unsigned long arg5);
> -- 
> 2.34.1
> 

Re: [PATCH v2 0/2] tools/nolibc: add pipe(), pipe2() and their testcase

[Yuan Tan]

Hi Thomas,

On Mon, 2023-07-31 at 08:13 +0200, Thomas Weißschuh wrote:
> Hi Yuan!
> 
> On 2023-07-31 13:50:31+0800, Yuan Tan wrote:
> > Thanks to your advice and I really learned a lot from it.
> > 
> > V2 now uses pipe2() to wrap pipe(), and fixes the strcmp issue in
> > test
> > case.
> 
> Thanks!
> 
> I have some more comments for the patches.
> 
> For new revisions you should also link to the old revision.
> 

I sincerely appreciate your valuable advice. As a newcomer, I will
certainly take note of it next time. :)

> > Best regards,
> > Yuan Tan
> > 
> > Yuan Tan (2):
> >   tools/nolibc: add pipe() and pipe2() support
> >   selftests/nolibc: add testcase for pipe
> > 
> >  tools/include/nolibc/sys.h                   | 24 ++++++++++++++
> >  tools/testing/selftests/nolibc/nolibc-test.c | 35
> > ++++++++++++++++++++
> >  2 files changed, 59 insertions(+)
> > 
> > -- 
> > 2.34.1
> > 
> 

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

[Yuan Tan]

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
> > 
> 

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

[Thomas Weißschuh]

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.

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

[Yuan Tan]

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.

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

[Thomas Weißschuh]

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.
> 

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

[Yuan Tan]

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);
}

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

[Thomas Weißschuh]

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)

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

[Yuan Tan]

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?

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

[Thomas Weißschuh]

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.