Re: [PATCH v3 16/16] kunit: uapi: Validate usability of /proc

[Thomas Weißschuh]

On Fri, Jun 20, 2025 at 05:48:07PM +0800, David Gow wrote:
> On Wed, 11 Jun 2025 at 15:38, Thomas Weißschuh
> <thomas.weissschuh@xxxxxxxxxxxxx> wrote:
> >
> > Show that the selftests are executed from a fairly "normal"
> > userspace context.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> > ---
> 
> This is good. I'm not 100% sure the example test is the best place for
> it, though.
> 
> Would it make more sense to either have this:
> - in the main kunit test (since it's really _verifying_ the KUnit
> environment, rather than documenting it)
> - in a separate kunit-uapi test (if we want to keep some separation
> between the UAPI and entirely in-kernel tests)
> - in a separate procfs test (since it tests procfs functionality as
> much as it's testing the KUnit environment)

Originally this change was really meant as an example for users.
But moving it into the main kunit test probably makes more sense.

> Personally, my gut feeling is the main kunit-test is the best place
> for this, even if it means spinning up a separate file is best here.

Ack.

> As for the actual implementation, though, that looks fine to me. A few
> small comments below, but nothing particularly important.
> 
> Reviewed-by: David Gow <davidgow@xxxxxxxxxx>
> 
> Cheers,
> -- David
> 
> >  lib/kunit/kunit-example-uapi.c | 34 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/kunit/kunit-example-uapi.c b/lib/kunit/kunit-example-uapi.c
> > index 4ce657050dd4a576632a41ca0309c4cb5134ce14..5e7a0f3b68f182c42b03e667567e66f02d8c2b86 100644
> > --- a/lib/kunit/kunit-example-uapi.c
> > +++ b/lib/kunit/kunit-example-uapi.c
> > @@ -8,13 +8,45 @@
> >   * This is *userspace* code.
> >   */
> >
> > +#include <fcntl.h>
> > +#include <unistd.h>
> > +#include <string.h>
> > +
> >  #include "../../tools/testing/selftests/kselftest.h"
> >
> > +static void test_procfs(void)
> > +{
> > +       char buf[256];
> > +       ssize_t r;
> > +       int fd;
> > +
> > +       fd = open("/proc/self/comm", O_RDONLY);
> > +       if (fd == -1) {
> > +               ksft_test_result_fail("procfs: open() failed: %s\n", strerror(errno));
> > +               return;
> > +       }
> > +
> > +       r = read(fd, buf, sizeof(buf));
> > +       close(fd);
> > +
> > +       if (r == -1) {
> > +               ksft_test_result_fail("procfs: read() failed: %s\n", strerror(errno));
> > +               return;
> > +       }
> > +
> 
> Do we want to use TASK_COMM_LEN rather than hardcoding 16 below?

> (And, if so, do we need something more complicated in case it's not 16?)

TASK_COMM_LEN is not part of the UAPI headers.
But I don't think it can ever change.

> > +       if (r != 16 || strncmp("kunit-example-u\n", buf, 16) != 0) {
> > +               ksft_test_result_fail("procfs: incorrect comm\n");
> > +               return;
> > +       }
> > +
> > +       ksft_test_result_pass("procfs\n");
> > +}
> > +
> >  int main(void)
> >  {
> >         ksft_print_header();
> >         ksft_set_plan(4);
> > -       ksft_test_result_pass("userspace test 1\n");
> > +       test_procfs();
> >         ksft_test_result_pass("userspace test 2\n");
> >         ksft_test_result_skip("userspace test 3: some reason\n");
> >         ksft_test_result_pass("userspace test 4\n");
> >
> > --
> > 2.49.0
> >