diff mbox series

[v4,17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()

Message ID 20190514221711.248228-18-brendanhiggins@google.com (mailing list archive)
State Superseded, archived
Headers show
Series kunit: introduce KUnit, the Linux kernel unit testing framework | expand

Commit Message

Brendan Higgins May 14, 2019, 10:17 p.m. UTC
From: Iurii Zaikin <yzaikin@google.com>

KUnit tests for initialized data behavior of proc_dointvec that is
explicitly checked in the code. Includes basic parsing tests including
int min/max overflow.

Signed-off-by: Iurii Zaikin <yzaikin@google.com>
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
---
 kernel/Makefile      |   2 +
 kernel/sysctl-test.c | 293 +++++++++++++++++++++++++++++++++++++++++++
 lib/Kconfig.debug    |   6 +
 3 files changed, 301 insertions(+)
 create mode 100644 kernel/sysctl-test.c

Comments

Stephen Boyd May 17, 2019, 6:22 p.m. UTC | #1
Quoting Brendan Higgins (2019-05-14 15:17:10)
> diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> new file mode 100644
> index 0000000000000..fe0f2bae66085
> --- /dev/null
> +++ b/kernel/sysctl-test.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test of proc sysctl.
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/printk.h>

Is this include used?

> +#include <linux/sysctl.h>
> +#include <linux/uaccess.h>

Is this include used?

> +
> +
> +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> +{
> +       struct ctl_table table = {
> +               .procname = "foo",
> +               .data           = &test_data.int_0001,
> +               .maxlen         = sizeof(int),
> +               .mode           = 0644,
> +               .proc_handler   = proc_dointvec,
> +               .extra1         = &i_zero,
> +               .extra2         = &i_one_hundred,
> +       };
> +       char input[] = "-9";
> +       size_t len = sizeof(input) - 1;
> +       loff_t pos = 0;
> +
> +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);

Is the casting necessary? Or can the macro do a type coercion of the
second parameter based on the first type?

> +}
> +
> +static void sysctl_test_dointvec_single_less_int_min(struct kunit *test)
> +{
> +       struct ctl_table table = {
> +               .procname = "foo",
> +               .data           = &test_data.int_0001,
> +               .maxlen         = sizeof(int),
> +               .mode           = 0644,
> +               .proc_handler   = proc_dointvec,
> +               .extra1         = &i_zero,
> +               .extra2         = &i_one_hundred,
> +       };
> +       char input[32];
> +       size_t len = sizeof(input) - 1;
> +       loff_t pos = 0;
> +       unsigned long abs_of_less_than_min = (unsigned long)INT_MAX
> +                                            - (INT_MAX + INT_MIN) + 1;
> +
> +       KUNIT_EXPECT_LT(test,
> +                       snprintf(input, sizeof(input), "-%lu",
> +                                abs_of_less_than_min),
> +                       sizeof(input));
> +
> +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> +       KUNIT_EXPECT_EQ(test, -EINVAL,
> +                       proc_dointvec(&table, 1, input, &len, &pos));
> +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> +       KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> +}
> +
> +static void sysctl_test_dointvec_single_greater_int_max(struct kunit *test)
> +{
> +       struct ctl_table table = {
> +               .procname = "foo",
> +               .data           = &test_data.int_0001,
> +               .maxlen         = sizeof(int),
> +               .mode           = 0644,
> +               .proc_handler   = proc_dointvec,
> +               .extra1         = &i_zero,
> +               .extra2         = &i_one_hundred,
> +       };
> +       char input[32];
> +       size_t len = sizeof(input) - 1;
> +       loff_t pos = 0;
> +       unsigned long greater_than_max = (unsigned long)INT_MAX + 1;
> +
> +       KUNIT_EXPECT_GT(test, greater_than_max, INT_MAX);
> +       KUNIT_EXPECT_LT(test, snprintf(input, sizeof(input), "%lu",
> +                                      greater_than_max),
> +                       sizeof(input));
> +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> +       KUNIT_EXPECT_EQ(test, -EINVAL,
> +                       proc_dointvec(&table, 1, input, &len, &pos));
> +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> +       KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> +}
> +
> +static int sysctl_test_init(struct kunit *test)
> +{
> +       return 0;
> +}
> +
> +/*
> + * This is run once after each test case, see the comment on example_test_module
> + * for more information.
> + */
> +static void sysctl_test_exit(struct kunit *test)
> +{
> +}

Can the above two be omitted? If they can be empty sometimes it would be
nice to avoid the extra symbols and code by letting them be assigned to
NULL in the kunit_module.

> +
> +/*
> + * Here we make a list of all the test cases we want to add to the test module
> + * below.
> + */
> +static struct kunit_case sysctl_test_cases[] = {
> +       /*
> +        * This is a helper to create a test case object from a test case
> +        * function; its exact function is not important to understand how to
> +        * use KUnit, just know that this is how you associate test cases with a
> +        * test module.
> +        */
> +       KUNIT_CASE(sysctl_test_dointvec_null_tbl_data),
> +       KUNIT_CASE(sysctl_test_dointvec_table_maxlen_unset),
> +       KUNIT_CASE(sysctl_test_dointvec_table_len_is_zero),
> +       KUNIT_CASE(sysctl_test_dointvec_table_read_but_position_set),
> +       KUNIT_CASE(sysctl_test_dointvec_happy_single_positive),
> +       KUNIT_CASE(sysctl_test_dointvec_happy_single_negative),
> +       KUNIT_CASE(sysctl_test_dointvec_single_less_int_min),
> +       KUNIT_CASE(sysctl_test_dointvec_single_greater_int_max),
> +       {},
> +};
> +
> +/*
> + * This defines a suite or grouping of tests.
> + *
> + * Test cases are defined as belonging to the suite by adding them to
> + * `test_cases`.
> + *
> + * Often it is desirable to run some function which will set up things which
> + * will be used by every test; this is accomplished with an `init` function
> + * which runs before each test case is invoked. Similarly, an `exit` function
> + * may be specified which runs after every test case and can be used to for
> + * cleanup. For clarity, running tests in a test module would behave as follows:
> + *
> + * module.init(test);
> + * module.test_case[0](test);
> + * module.exit(test);
> + * module.init(test);
> + * module.test_case[1](test);
> + * module.exit(test);
> + * ...;

This comment (and the one above for "this is a helper") looks generic
and should probably only be in some documentation somewhere and not for
a sysctl test?

> + */
> +static struct kunit_module sysctl_test_module = {
> +       .name = "sysctl_test",
> +       .init = sysctl_test_init,
> +       .exit = sysctl_test_exit,
> +       .test_cases = sysctl_test_cases,
> +};
> +
> +/*
> + * This registers the above test module telling KUnit that this is a suite of
> + * tests that need to be run.
> + */

Same comment about generic comment.

> +module_test(sysctl_test_module);
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d5a4a4036d2f8..772af4ec70111 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1908,6 +1908,12 @@ config TEST_SYSCTL
>  
>           If unsure, say N.
>  
> +config SYSCTL_KUNIT_TEST
> +       bool "KUnit test for sysctl"

Why not tristate?

> +       depends on KUNIT
> +       help
> +         Enables KUnit sysctl test.
> +
Iurii Zaikin June 6, 2019, 1:29 a.m. UTC | #2
On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:17:10)
> > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > new file mode 100644
> > index 0000000000000..fe0f2bae66085
> > --- /dev/null
> > +++ b/kernel/sysctl-test.c
> > @@ -0,0 +1,293 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * KUnit test of proc sysctl.
> > + */
> > +
> > +#include <kunit/test.h>
> > +#include <linux/printk.h>
>
> Is this include used?
  Deleted.
>
> > +#include <linux/sysctl.h>
> > +#include <linux/uaccess.h>
>
> Is this include used?
Deleted.
>
> > +
> > +
> > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > +{
> > +       struct ctl_table table = {
> > +               .procname = "foo",
> > +               .data           = &test_data.int_0001,
> > +               .maxlen         = sizeof(int),
> > +               .mode           = 0644,
> > +               .proc_handler   = proc_dointvec,
> > +               .extra1         = &i_zero,
> > +               .extra2         = &i_one_hundred,
> > +       };
> > +       char input[] = "-9";
> > +       size_t len = sizeof(input) - 1;
> > +       loff_t pos = 0;
> > +
> > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
>
> Is the casting necessary? Or can the macro do a type coercion of the
> second parameter based on the first type?
 Data field is defined as void* so I believe casting is necessary to
dereference it as a pointer to an array of ints. I don't think the
macro should do any type coercion that == operator wouldn't do.
 I did change the cast to make it more clear that it's a pointer to an
array of ints being dereferenced.
>
> > +}
> > +
> > +static void sysctl_test_dointvec_single_less_int_min(struct kunit *test)
> > +{
> > +       struct ctl_table table = {
> > +               .procname = "foo",
> > +               .data           = &test_data.int_0001,
> > +               .maxlen         = sizeof(int),
> > +               .mode           = 0644,
> > +               .proc_handler   = proc_dointvec,
> > +               .extra1         = &i_zero,
> > +               .extra2         = &i_one_hundred,
> > +       };
> > +       char input[32];
> > +       size_t len = sizeof(input) - 1;
> > +       loff_t pos = 0;
> > +       unsigned long abs_of_less_than_min = (unsigned long)INT_MAX
> > +                                            - (INT_MAX + INT_MIN) + 1;
> > +
> > +       KUNIT_EXPECT_LT(test,
> > +                       snprintf(input, sizeof(input), "-%lu",
> > +                                abs_of_less_than_min),
> > +                       sizeof(input));
> > +
> > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > +       KUNIT_EXPECT_EQ(test, -EINVAL,
> > +                       proc_dointvec(&table, 1, input, &len, &pos));
> > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > +       KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> > +}
> > +
> > +static void sysctl_test_dointvec_single_greater_int_max(struct kunit *test)
> > +{
> > +       struct ctl_table table = {
> > +               .procname = "foo",
> > +               .data           = &test_data.int_0001,
> > +               .maxlen         = sizeof(int),
> > +               .mode           = 0644,
> > +               .proc_handler   = proc_dointvec,
> > +               .extra1         = &i_zero,
> > +               .extra2         = &i_one_hundred,
> > +       };
> > +       char input[32];
> > +       size_t len = sizeof(input) - 1;
> > +       loff_t pos = 0;
> > +       unsigned long greater_than_max = (unsigned long)INT_MAX + 1;
> > +
> > +       KUNIT_EXPECT_GT(test, greater_than_max, INT_MAX);
> > +       KUNIT_EXPECT_LT(test, snprintf(input, sizeof(input), "%lu",
> > +                                      greater_than_max),
> > +                       sizeof(input));
> > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > +       KUNIT_EXPECT_EQ(test, -EINVAL,
> > +                       proc_dointvec(&table, 1, input, &len, &pos));
> > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > +       KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
> > +}
> > +
> > +static int sysctl_test_init(struct kunit *test)
> > +{
> > +       return 0;
> > +}
> > +
> > +/*
> > + * This is run once after each test case, see the comment on example_test_module
> > + * for more information.
> > + */
> > +static void sysctl_test_exit(struct kunit *test)
> > +{
> > +}
> Can the above two be omitted? If they can be empty sometimes it would be
> nice to avoid the extra symbols and code by letting them be assigned to
> NULL in the kunit_module.
 Deleted.
>
> > +
> > +/*
> > + * Here we make a list of all the test cases we want to add to the test module
> > + * below.
> > + */
> > +static struct kunit_case sysctl_test_cases[] = {
> > +       /*
> > +        * This is a helper to create a test case object from a test case
> > +        * function; its exact function is not important to understand how to
> > +        * use KUnit, just know that this is how you associate test cases with a
> > +        * test module.
> > +        */
> > +       KUNIT_CASE(sysctl_test_dointvec_null_tbl_data),
> > +       KUNIT_CASE(sysctl_test_dointvec_table_maxlen_unset),
> > +       KUNIT_CASE(sysctl_test_dointvec_table_len_is_zero),
> > +       KUNIT_CASE(sysctl_test_dointvec_table_read_but_position_set),
> > +       KUNIT_CASE(sysctl_test_dointvec_happy_single_positive),
> > +       KUNIT_CASE(sysctl_test_dointvec_happy_single_negative),
> > +       KUNIT_CASE(sysctl_test_dointvec_single_less_int_min),
> > +       KUNIT_CASE(sysctl_test_dointvec_single_greater_int_max),
> > +       {},
> > +};
> > +
> > +/*
> > + * This defines a suite or grouping of tests.
> > + *
> > + * Test cases are defined as belonging to the suite by adding them to
> > + * `test_cases`.
> > + *
> > + * Often it is desirable to run some function which will set up things which
> > + * will be used by every test; this is accomplished with an `init` function
> > + * which runs before each test case is invoked. Similarly, an `exit` function
> > + * may be specified which runs after every test case and can be used to for
> > + * cleanup. For clarity, running tests in a test module would behave as follows:
> > + *
> > + * module.init(test);
> > + * module.test_case[0](test);
> > + * module.exit(test);
> > + * module.init(test);
> > + * module.test_case[1](test);
> > + * module.exit(test);
> > + * ...;
>
> This comment (and the one above for "this is a helper") looks generic
> and should probably only be in some documentation somewhere and not for
> a sysctl test?
>
Deleted.
> > + */
> > +static struct kunit_module sysctl_test_module = {
> > +       .name = "sysctl_test",
> > +       .init = sysctl_test_init,
> > +       .exit = sysctl_test_exit,
> > +       .test_cases = sysctl_test_cases,
> > +};
> > +
> > +/*
> > + * This registers the above test module telling KUnit that this is a suite of
> > + * tests that need to be run.
> > + */
>
> Same comment about generic comment.
>
Deleted.
> > +module_test(sysctl_test_module);
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index d5a4a4036d2f8..772af4ec70111 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -1908,6 +1908,12 @@ config TEST_SYSCTL
> >
> >           If unsure, say N.
> >
> > +config SYSCTL_KUNIT_TEST
> > +       bool "KUnit test for sysctl"
>
> Why not tristate?
>
I don't believe KUnit as a module is currently supported.
> > +       depends on KUNIT
> > +       help
> > +         Enables KUnit sysctl test.
> > +
Stephen Boyd June 7, 2019, 7 p.m. UTC | #3
Quoting Iurii Zaikin (2019-06-05 18:29:42)
> On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > new file mode 100644
> > > index 0000000000000..fe0f2bae66085
> > > --- /dev/null
> > > +++ b/kernel/sysctl-test.c
> > > +
> > > +
> > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > +{
> > > +       struct ctl_table table = {
> > > +               .procname = "foo",
> > > +               .data           = &test_data.int_0001,
> > > +               .maxlen         = sizeof(int),
> > > +               .mode           = 0644,
> > > +               .proc_handler   = proc_dointvec,
> > > +               .extra1         = &i_zero,
> > > +               .extra2         = &i_one_hundred,
> > > +       };
> > > +       char input[] = "-9";
> > > +       size_t len = sizeof(input) - 1;
> > > +       loff_t pos = 0;
> > > +
> > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> >
> > Is the casting necessary? Or can the macro do a type coercion of the
> > second parameter based on the first type?
>  Data field is defined as void* so I believe casting is necessary to
> dereference it as a pointer to an array of ints. I don't think the
> macro should do any type coercion that == operator wouldn't do.
>  I did change the cast to make it more clear that it's a pointer to an
> array of ints being dereferenced.

Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
both sides and cause a build warning/error if the types aren't the same.
This would be similar to our min/max macros that complain about
mismatched types in the comparisons. Then if a test developer needs to
convert one type or the other they could do so with a
KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
explicitly.
Brendan Higgins June 7, 2019, 10:22 p.m. UTC | #4
On Fri, Jun 7, 2019 at 12:00 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > new file mode 100644
> > > > index 0000000000000..fe0f2bae66085
> > > > --- /dev/null
> > > > +++ b/kernel/sysctl-test.c
> > > > +
> > > > +
> > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > > +{
> > > > +       struct ctl_table table = {
> > > > +               .procname = "foo",
> > > > +               .data           = &test_data.int_0001,
> > > > +               .maxlen         = sizeof(int),
> > > > +               .mode           = 0644,
> > > > +               .proc_handler   = proc_dointvec,
> > > > +               .extra1         = &i_zero,
> > > > +               .extra2         = &i_one_hundred,
> > > > +       };
> > > > +       char input[] = "-9";
> > > > +       size_t len = sizeof(input) - 1;
> > > > +       loff_t pos = 0;
> > > > +
> > > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> > >
> > > Is the casting necessary? Or can the macro do a type coercion of the
> > > second parameter based on the first type?
> >  Data field is defined as void* so I believe casting is necessary to
> > dereference it as a pointer to an array of ints. I don't think the
> > macro should do any type coercion that == operator wouldn't do.
> >  I did change the cast to make it more clear that it's a pointer to an
> > array of ints being dereferenced.
>
> Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
> both sides and cause a build warning/error if the types aren't the same.
> This would be similar to our min/max macros that complain about
> mismatched types in the comparisons. Then if a test developer needs to
> convert one type or the other they could do so with a
> KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
> explicitly.

Good point. I would definitely like to do this, for me it is only a
question of how difficult it would be to make all that happen.

We will investigate and report back on it.

Thanks for the suggestion! It's a really good idea!

Cheers
Brendan Higgins June 11, 2019, 5:58 p.m. UTC | #5
On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > new file mode 100644
> > > > index 0000000000000..fe0f2bae66085
> > > > --- /dev/null
> > > > +++ b/kernel/sysctl-test.c
> > > > +
> > > > +
> > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > > +{
> > > > +       struct ctl_table table = {
> > > > +               .procname = "foo",
> > > > +               .data           = &test_data.int_0001,
> > > > +               .maxlen         = sizeof(int),
> > > > +               .mode           = 0644,
> > > > +               .proc_handler   = proc_dointvec,
> > > > +               .extra1         = &i_zero,
> > > > +               .extra2         = &i_one_hundred,
> > > > +       };
> > > > +       char input[] = "-9";
> > > > +       size_t len = sizeof(input) - 1;
> > > > +       loff_t pos = 0;
> > > > +
> > > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> > >
> > > Is the casting necessary? Or can the macro do a type coercion of the
> > > second parameter based on the first type?
> >  Data field is defined as void* so I believe casting is necessary to
> > dereference it as a pointer to an array of ints. I don't think the
> > macro should do any type coercion that == operator wouldn't do.
> >  I did change the cast to make it more clear that it's a pointer to an
> > array of ints being dereferenced.
> 
> Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
> both sides and cause a build warning/error if the types aren't the same.
> This would be similar to our min/max macros that complain about
> mismatched types in the comparisons. Then if a test developer needs to
> convert one type or the other they could do so with a
> KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
> explicitly.

Do you think it would be better to do a phony compare similar to how
min/max used to work prior to 4.17, or to use the new __typecheck(...)
macro? This might seem like a dumb question (and maybe it is), but Iurii
and I thought the former created an error message that was a bit easier
to understand, whereas __typecheck is obviously superior in terms of
code reuse.

This is what we are thinking right now; if you don't have any complaints
I will squash it into the relevant commits on the next revision:
---
From: Iurii Zaikin <yzaikin@google.com>

Adds a warning message when comparing values of different types similar
to what min() / max() macros do.

Signed-off-by: Iurii Zaikin <yzaikin@google.com>
---
 include/kunit/test.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 511c9e85401a6..791e22fba5620 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -335,6 +335,13 @@ void __printf(3, 4) kunit_printk(const char *level,
 #define kunit_err(test, fmt, ...) \
 		kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
 
+/*
+ * 'Unnecessary' cast serves to generate a compile-time warning in case
+ * of comparing incompatible types. Inspired by include/linux/kernel.h
+ */
+#define __kunit_typecheck(lhs, rhs) \
+	((void) (&(lhs) == &(rhs)))
+
 static inline struct kunit_stream *kunit_expect_start(struct kunit *test,
 						      const char *file,
 						      const char *line)
@@ -514,6 +521,7 @@ static inline void kunit_expect_ptr_binary(struct kunit *test,
 #define KUNIT_EXPECT_BINARY(test, left, condition, right) do {		       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_expect_binary(test,					       \
 			    (long long) __left, #left,			       \
 			    (long long) __right, #right,		       \
@@ -524,6 +532,7 @@ static inline void kunit_expect_ptr_binary(struct kunit *test,
 #define KUNIT_EXPECT_BINARY_MSG(test, left, condition, right, fmt, ...) do {   \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_expect_binary_msg(test,					       \
 				(long long) __left, #left,		       \
 				(long long) __right, #right,		       \
@@ -538,6 +547,7 @@ static inline void kunit_expect_ptr_binary(struct kunit *test,
 #define KUNIT_EXPECT_PTR_BINARY(test, left, condition, right) do {	       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_expect_ptr_binary(test,					       \
 			    (void *) __left, #left,			       \
 			    (void *) __right, #right,			       \
@@ -553,6 +563,7 @@ static inline void kunit_expect_ptr_binary(struct kunit *test,
 				    ...) do {				       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_expect_ptr_binary_msg(test,				       \
 				    (void *) __left, #left,		       \
 				    (void *) __right, #right,		       \
@@ -1013,6 +1024,7 @@ static inline void kunit_assert_ptr_binary(struct kunit *test,
 #define KUNIT_ASSERT_BINARY(test, left, condition, right) do {		       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_assert_binary(test,					       \
 			    (long long) __left, #left,			       \
 			    (long long) __right, #right,		       \
@@ -1023,6 +1035,7 @@ static inline void kunit_assert_ptr_binary(struct kunit *test,
 #define KUNIT_ASSERT_BINARY_MSG(test, left, condition, right, fmt, ...) do {   \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_assert_binary_msg(test,					       \
 				(long long) __left, #left,		       \
 				(long long) __right, #right,		       \
@@ -1037,6 +1050,7 @@ static inline void kunit_assert_ptr_binary(struct kunit *test,
 #define KUNIT_ASSERT_PTR_BINARY(test, left, condition, right) do {	       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_assert_ptr_binary(test,					       \
 				(void *) __left, #left,			       \
 				(void *) __right, #right,		       \
@@ -1051,6 +1065,7 @@ static inline void kunit_assert_ptr_binary(struct kunit *test,
 				    fmt, ...) do {			       \
 	typeof(left) __left = (left);					       \
 	typeof(right) __right = (right);				       \
+	__kunit_typecheck(__left, __right);				       \
 	kunit_assert_ptr_binary_msg(test,				       \
 				    (void *) __left, #left,		       \
 				    (void *) __right, #right,		       \
Stephen Boyd June 11, 2019, 6:50 p.m. UTC | #6
Quoting Brendan Higgins (2019-06-11 10:58:30)
> On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> > Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > > >
> > > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > > new file mode 100644
> > > > > index 0000000000000..fe0f2bae66085
> > > > > --- /dev/null
> > > > > +++ b/kernel/sysctl-test.c
> > > > > +
> > > > > +
> > > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > > > +{
> > > > > +       struct ctl_table table = {
> > > > > +               .procname = "foo",
> > > > > +               .data           = &test_data.int_0001,
> > > > > +               .maxlen         = sizeof(int),
> > > > > +               .mode           = 0644,
> > > > > +               .proc_handler   = proc_dointvec,
> > > > > +               .extra1         = &i_zero,
> > > > > +               .extra2         = &i_one_hundred,
> > > > > +       };
> > > > > +       char input[] = "-9";
> > > > > +       size_t len = sizeof(input) - 1;
> > > > > +       loff_t pos = 0;
> > > > > +
> > > > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> > > >
> > > > Is the casting necessary? Or can the macro do a type coercion of the
> > > > second parameter based on the first type?
> > >  Data field is defined as void* so I believe casting is necessary to
> > > dereference it as a pointer to an array of ints. I don't think the
> > > macro should do any type coercion that == operator wouldn't do.
> > >  I did change the cast to make it more clear that it's a pointer to an
> > > array of ints being dereferenced.
> > 
> > Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
> > both sides and cause a build warning/error if the types aren't the same.
> > This would be similar to our min/max macros that complain about
> > mismatched types in the comparisons. Then if a test developer needs to
> > convert one type or the other they could do so with a
> > KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
> > explicitly.
> 
> Do you think it would be better to do a phony compare similar to how
> min/max used to work prior to 4.17, or to use the new __typecheck(...)
> macro? This might seem like a dumb question (and maybe it is), but Iurii
> and I thought the former created an error message that was a bit easier
> to understand, whereas __typecheck is obviously superior in terms of
> code reuse.
> 
> This is what we are thinking right now; if you don't have any complaints
> I will squash it into the relevant commits on the next revision:

Can you provide the difference in error messages and describe that in
the commit text? The commit message is where you "sell" the patch, so
being able to compare the tradeoff of having another macro to do type
comparisons vs. reusing the one that's there in kernel.h would be useful
to allay concerns that we're duplicating logic for better error
messages.

Honestly, I'd prefer we just use the macros that we've developed in
kernel.h to do comparisons here so that we can get code reuse, but more
importantly so that we don't trip over problems that caused those macros
to be created in the first place. If the error message is bad, perhaps
that can be fixed with some sort of compiler directive to make the error
message a little more useful, i.e. compiletime_warning() thrown into
__typecheck() or something.

> ---
> From: Iurii Zaikin <yzaikin@google.com>
> 
> Adds a warning message when comparing values of different types similar
> to what min() / max() macros do.
> 
> Signed-off-by: Iurii Zaikin <yzaikin@google.com>
Brendan Higgins June 11, 2019, 8:29 p.m. UTC | #7
On Tue, Jun 11, 2019 at 11:50 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-06-11 10:58:30)
> > On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> > > Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > > > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > >
> > > > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > > > new file mode 100644
> > > > > > index 0000000000000..fe0f2bae66085
> > > > > > --- /dev/null
> > > > > > +++ b/kernel/sysctl-test.c
> > > > > > +
> > > > > > +
> > > > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
> > > > > > +{
> > > > > > +       struct ctl_table table = {
> > > > > > +               .procname = "foo",
> > > > > > +               .data           = &test_data.int_0001,
> > > > > > +               .maxlen         = sizeof(int),
> > > > > > +               .mode           = 0644,
> > > > > > +               .proc_handler   = proc_dointvec,
> > > > > > +               .extra1         = &i_zero,
> > > > > > +               .extra2         = &i_one_hundred,
> > > > > > +       };
> > > > > > +       char input[] = "-9";
> > > > > > +       size_t len = sizeof(input) - 1;
> > > > > > +       loff_t pos = 0;
> > > > > > +
> > > > > > +       table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
> > > > > > +       KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
> > > > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
> > > > > > +       KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
> > > > > > +       KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
> > > > >
> > > > > Is the casting necessary? Or can the macro do a type coercion of the
> > > > > second parameter based on the first type?
> > > >  Data field is defined as void* so I believe casting is necessary to
> > > > dereference it as a pointer to an array of ints. I don't think the
> > > > macro should do any type coercion that == operator wouldn't do.
> > > >  I did change the cast to make it more clear that it's a pointer to an
> > > > array of ints being dereferenced.
> > >
> > > Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on
> > > both sides and cause a build warning/error if the types aren't the same.
> > > This would be similar to our min/max macros that complain about
> > > mismatched types in the comparisons. Then if a test developer needs to
> > > convert one type or the other they could do so with a
> > > KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to
> > > explicitly.
> >
> > Do you think it would be better to do a phony compare similar to how
> > min/max used to work prior to 4.17, or to use the new __typecheck(...)
> > macro? This might seem like a dumb question (and maybe it is), but Iurii
> > and I thought the former created an error message that was a bit easier
> > to understand, whereas __typecheck is obviously superior in terms of
> > code reuse.
> >
> > This is what we are thinking right now; if you don't have any complaints
> > I will squash it into the relevant commits on the next revision:
>
> Can you provide the difference in error messages and describe that in
> the commit text? The commit message is where you "sell" the patch, so
> being able to compare the tradeoff of having another macro to do type
> comparisons vs. reusing the one that's there in kernel.h would be useful
> to allay concerns that we're duplicating logic for better error
> messages.

Oh sorry, I didn't think too hard about the commit message since I
figured it would get split up and squashed into the existing commits.
I just wanted to get it out sooner to discuss this before I post the
next revision (probably later this week).

> Honestly, I'd prefer we just use the macros that we've developed in
> kernel.h to do comparisons here so that we can get code reuse, but more
> importantly so that we don't trip over problems that caused those macros
> to be created in the first place. If the error message is bad, perhaps
> that can be fixed with some sort of compiler directive to make the error
> message a little more useful, i.e. compiletime_warning() thrown into
> __typecheck() or something.

That's a good point. I have no qualms sticking with __typecheck(...)
for now; if we later feel that it is causing problems, we can always
fix it later by supplying our own warning in the manner you suggest.

Iurii, do you have any additional thoughts on this?

>
> > ---
> > From: Iurii Zaikin <yzaikin@google.com>
> >
> > Adds a warning message when comparing values of different types similar
> > to what min() / max() macros do.
> >
> > Signed-off-by: Iurii Zaikin <yzaikin@google.com>
diff mbox series

Patch

diff --git a/kernel/Makefile b/kernel/Makefile
index 6c57e78817dad..c81a8976b6a4b 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -112,6 +112,8 @@  obj-$(CONFIG_HAS_IOMEM) += iomem.o
 obj-$(CONFIG_ZONE_DEVICE) += memremap.o
 obj-$(CONFIG_RSEQ) += rseq.o
 
+obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o
+
 obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += stackleak.o
 KASAN_SANITIZE_stackleak.o := n
 KCOV_INSTRUMENT_stackleak.o := n
diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
new file mode 100644
index 0000000000000..fe0f2bae66085
--- /dev/null
+++ b/kernel/sysctl-test.c
@@ -0,0 +1,293 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test of proc sysctl.
+ */
+
+#include <kunit/test.h>
+#include <linux/printk.h>
+#include <linux/sysctl.h>
+#include <linux/uaccess.h>
+
+static int i_zero;
+static int i_one_hundred = 100;
+
+struct test_sysctl_data {
+	int int_0001;
+	int int_0002;
+	int int_0003[4];
+
+	unsigned int uint_0001;
+
+	char string_0001[65];
+};
+
+static struct test_sysctl_data test_data = {
+	.int_0001 = 60,
+	.int_0002 = 1,
+
+	.int_0003[0] = 0,
+	.int_0003[1] = 1,
+	.int_0003[2] = 2,
+	.int_0003[3] = 3,
+
+	.uint_0001 = 314,
+
+	.string_0001 = "(none)",
+};
+
+static void sysctl_test_dointvec_null_tbl_data(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= NULL,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	size_t len;
+	loff_t pos;
+
+	len = 1234;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 0, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+	len = 1234;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_maxlen_unset(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= 0,
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	size_t len;
+	loff_t pos;
+
+	len = 1234;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 0, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+	len = 1234;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_len_is_zero(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	size_t len;
+	loff_t pos;
+
+	len = 0;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 0, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_table_read_but_position_set(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	void  *buffer = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	size_t len;
+	loff_t pos;
+
+	len = 1234;
+	pos = 1;
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 0, buffer, &len, &pos));
+	KUNIT_EXPECT_EQ(test, 0, len);
+}
+
+static void sysctl_test_dointvec_happy_single_positive(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	char input[] = "9";
+	size_t len = sizeof(input) - 1;
+	loff_t pos = 0;
+
+	table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
+	KUNIT_EXPECT_EQ(test, 9, *(int *)table.data);
+}
+
+static void sysctl_test_dointvec_happy_single_negative(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	char input[] = "-9";
+	size_t len = sizeof(input) - 1;
+	loff_t pos = 0;
+
+	table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos));
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos);
+	KUNIT_EXPECT_EQ(test, -9, *(int *)table.data);
+}
+
+static void sysctl_test_dointvec_single_less_int_min(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	char input[32];
+	size_t len = sizeof(input) - 1;
+	loff_t pos = 0;
+	unsigned long abs_of_less_than_min = (unsigned long)INT_MAX
+					     - (INT_MAX + INT_MIN) + 1;
+
+	KUNIT_EXPECT_LT(test,
+			snprintf(input, sizeof(input), "-%lu",
+				 abs_of_less_than_min),
+			sizeof(input));
+
+	table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	KUNIT_EXPECT_EQ(test, -EINVAL,
+			proc_dointvec(&table, 1, input, &len, &pos));
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
+	KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
+}
+
+static void sysctl_test_dointvec_single_greater_int_max(struct kunit *test)
+{
+	struct ctl_table table = {
+		.procname = "foo",
+		.data		= &test_data.int_0001,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+		.extra1		= &i_zero,
+		.extra2         = &i_one_hundred,
+	};
+	char input[32];
+	size_t len = sizeof(input) - 1;
+	loff_t pos = 0;
+	unsigned long greater_than_max = (unsigned long)INT_MAX + 1;
+
+	KUNIT_EXPECT_GT(test, greater_than_max, INT_MAX);
+	KUNIT_EXPECT_LT(test, snprintf(input, sizeof(input), "%lu",
+				       greater_than_max),
+			sizeof(input));
+	table.data = kunit_kzalloc(test, sizeof(int), GFP_USER);
+	KUNIT_EXPECT_EQ(test, -EINVAL,
+			proc_dointvec(&table, 1, input, &len, &pos));
+	KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len);
+	KUNIT_EXPECT_EQ(test, 0, *(int *)table.data);
+}
+
+static int sysctl_test_init(struct kunit *test)
+{
+	return 0;
+}
+
+/*
+ * This is run once after each test case, see the comment on example_test_module
+ * for more information.
+ */
+static void sysctl_test_exit(struct kunit *test)
+{
+}
+
+/*
+ * Here we make a list of all the test cases we want to add to the test module
+ * below.
+ */
+static struct kunit_case sysctl_test_cases[] = {
+	/*
+	 * This is a helper to create a test case object from a test case
+	 * function; its exact function is not important to understand how to
+	 * use KUnit, just know that this is how you associate test cases with a
+	 * test module.
+	 */
+	KUNIT_CASE(sysctl_test_dointvec_null_tbl_data),
+	KUNIT_CASE(sysctl_test_dointvec_table_maxlen_unset),
+	KUNIT_CASE(sysctl_test_dointvec_table_len_is_zero),
+	KUNIT_CASE(sysctl_test_dointvec_table_read_but_position_set),
+	KUNIT_CASE(sysctl_test_dointvec_happy_single_positive),
+	KUNIT_CASE(sysctl_test_dointvec_happy_single_negative),
+	KUNIT_CASE(sysctl_test_dointvec_single_less_int_min),
+	KUNIT_CASE(sysctl_test_dointvec_single_greater_int_max),
+	{},
+};
+
+/*
+ * This defines a suite or grouping of tests.
+ *
+ * Test cases are defined as belonging to the suite by adding them to
+ * `test_cases`.
+ *
+ * Often it is desirable to run some function which will set up things which
+ * will be used by every test; this is accomplished with an `init` function
+ * which runs before each test case is invoked. Similarly, an `exit` function
+ * may be specified which runs after every test case and can be used to for
+ * cleanup. For clarity, running tests in a test module would behave as follows:
+ *
+ * module.init(test);
+ * module.test_case[0](test);
+ * module.exit(test);
+ * module.init(test);
+ * module.test_case[1](test);
+ * module.exit(test);
+ * ...;
+ */
+static struct kunit_module sysctl_test_module = {
+	.name = "sysctl_test",
+	.init = sysctl_test_init,
+	.exit = sysctl_test_exit,
+	.test_cases = sysctl_test_cases,
+};
+
+/*
+ * This registers the above test module telling KUnit that this is a suite of
+ * tests that need to be run.
+ */
+module_test(sysctl_test_module);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d5a4a4036d2f8..772af4ec70111 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1908,6 +1908,12 @@  config TEST_SYSCTL
 
 	  If unsure, say N.
 
+config SYSCTL_KUNIT_TEST
+	bool "KUnit test for sysctl"
+	depends on KUNIT
+	help
+	  Enables KUnit sysctl test.
+
 config TEST_UDELAY
 	tristate "udelay test driver"
 	help