| Message ID | 9221753abe0509ef5cbb474a31873012e0e40706.1690733545.git.tanyuan@tinylab.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | tools/nolibc: add pipe(), pipe2() and their testcase | expand |
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 >
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 > > >
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.
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.
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. >
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); }
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)
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?
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 --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.
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(+)