All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	keescook-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
	mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: brakmo-b10kYP2dOMg@public.gmane.org,
	pmladek-IBi9RG/b67k@public.gmane.org,
	amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Brendan Higgins
	<brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Alexander.Levin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org,
	linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	richard-/L3Ra7n9ekc@public.gmane.org,
	knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
	wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org,
	jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org,
	dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tim.Bird-7U/KSKJipcs@public.gmane.org,
	linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org,
	julia.lawall-L2FTfq7BK8M@public.gmane.org,
	kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	daniel-/w4YWyX8dFk@public.gmane.org,
	mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org,
	joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org,
	khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
Subject: Re: [RFC v4 08/17] kunit: test: add support for test abort
Date: Tue, 26 Feb 2019 12:35:45 -0800	[thread overview]
Message-ID: <155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190214213729.21702-9-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.

Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?

For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.

> 
> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0000000000000..a936c041f1c8f

Could this whole file be another patch? It seems to be a test for the
try catch mechanism.

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->context.try_result = -EFAULT;
> +       complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> +       struct kunit_try_catch *try_catch = data;
>  
> +       try_catch->try(&try_catch->context);
> +
> +       complete_and_exit(try_catch->context.try_completion, 0);

The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.

> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> +       struct task_struct *task_struct;
> +       struct kunit *test = try_catch->context.test;
> +       int exit_code, wake_result;
> +       DECLARE_COMPLETION(test_case_completion);

DECLARE_COMPLETION_ONSTACK()?

> +
> +       try_catch->context.try_completion = &test_case_completion;
> +       try_catch->context.try_result = 0;
> +       task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +                                            try_catch,
> +                                            "kunit_try_catch_thread");
> +       if (IS_ERR_OR_NULL(task_struct)) {

It looks like NULL is never returned from kthread_create(), so don't
check for it here.

> +               try_catch->catch(&try_catch->context);
> +               return;
> +       }
> +
> +       wake_result = wake_up_process(task_struct);
> +       if (wake_result != 0 && wake_result != 1) {

These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?

> +               kunit_err(test, "task was not woken properly: %d", wake_result);
> +               try_catch->catch(&try_catch->context);
> +       }
> +
> +       /*
> +        * TODO(brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org): We should probably have some type of
> +        * timeout here. The only question is what that timeout value should be.
> +        *
> +        * The intention has always been, at some point, to be able to label
> +        * tests with some type of size bucket (unit/small, integration/medium,
> +        * large/system/end-to-end, etc), where each size bucket would get a
> +        * default timeout value kind of like what Bazel does:
> +        * https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +        * There is still some debate to be had on exactly how we do this. (For
> +        * one, we probably want to have some sort of test runner level
> +        * timeout.)
> +        *
> +        * For more background on this topic, see:
> +        * https://mike-bland.com/2011/11/01/small-medium-large.html
> +        */
> +       wait_for_completion(&test_case_completion);

It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.

> +
> +       exit_code = try_catch->context.try_result;
> +       if (exit_code == -EFAULT)
> +               try_catch->catch(&try_catch->context);
> +       else if (exit_code == -EINTR)
> +               kunit_err(test, "wake_up_process() was never called.");

Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.

> +       else if (exit_code)
> +               kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->run = kunit_generic_run_try_catch;

Is the idea that 'run' would be anything besides
'kunit_generic_run_try_catch'? If it isn't going to be different, then
maybe it's simpler to just have a function like
kunit_generic_run_try_catch() that is called by the unit tests instead
of having to write 'try_catch->run(try_catch)' and indirect for the
basic case. Maybe I've missed the point entirely though and this is all
scaffolding for more complicated exception handling later on.

> +       try_catch->throw = kunit_generic_throw;
> +}
> +
> +void __weak kunit_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       kunit_generic_try_catch_init(try_catch);
> +}
> +
> +static void kunit_try_run_case(struct kunit_try_catch_context *context)
> +{
> +       struct kunit_try_catch_context *ctx = context;
> +       struct kunit *test = ctx->test;
> +       struct kunit_module *module = ctx->module;
> +       struct kunit_case *test_case = ctx->test_case;
> +
> +       /*
> +        * kunit_run_case_internal may encounter a fatal error; if it does, we
> +        * will jump to ENTER_HANDLER above instead of continuing normal control

Where is 'ENTER_HANDLER' above?

> +        * flow.
> +        */
>         kunit_run_case_internal(test, module, test_case);
> +       /* This line may never be reached. */
>         kunit_run_case_cleanup(test, module, test_case);
> +}

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Brendan Higgins <brendanhiggins@google.com>,
	frowand.list@gmail.com, keescook@google.com,
	kieran.bingham@ideasonboard.com, mcgrof@kernel.org,
	robh@kernel.org, shuah@kernel.org
Cc: gregkh@linuxfoundation.org, joel@jms.id.au, mpe@ellerman.id.au,
	joe@perches.com, brakmo@fb.com, rostedt@goodmis.org,
	Tim.Bird@sony.com, khilman@baylibre.com, julia.lawall@lip6.fr,
	linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
	linux-kernel@vger.kernel.org, jdike@addtoit.com, richard@nod.at,
	linux-um@lists.infradead.org, daniel@ffwll.ch,
	dri-devel@lists.freedesktop.org, dan.j.williams@intel.com,
	linux-nvdimm@lists.01.org, knut.omang@oracle.com,
	devicetree@vger.kernel.org, pmladek@suse.com,
	Alexander.Levin@microsoft.com, amir73il@gmail.com,
	dan.carpenter@oracle.com, wfg@linux.intel.com,
	Brendan Higgins <brendanhiggins@google.com>
Subject: Re: [RFC v4 08/17] kunit: test: add support for test abort
Date: Tue, 26 Feb 2019 12:35:45 -0800	[thread overview]
Message-ID: <155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190214213729.21702-9-brendanhiggins@google.com>

Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.

Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?

For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.

> 
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0000000000000..a936c041f1c8f

Could this whole file be another patch? It seems to be a test for the
try catch mechanism.

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->context.try_result = -EFAULT;
> +       complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> +       struct kunit_try_catch *try_catch = data;
>  
> +       try_catch->try(&try_catch->context);
> +
> +       complete_and_exit(try_catch->context.try_completion, 0);

The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.

> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> +       struct task_struct *task_struct;
> +       struct kunit *test = try_catch->context.test;
> +       int exit_code, wake_result;
> +       DECLARE_COMPLETION(test_case_completion);

DECLARE_COMPLETION_ONSTACK()?

> +
> +       try_catch->context.try_completion = &test_case_completion;
> +       try_catch->context.try_result = 0;
> +       task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +                                            try_catch,
> +                                            "kunit_try_catch_thread");
> +       if (IS_ERR_OR_NULL(task_struct)) {

It looks like NULL is never returned from kthread_create(), so don't
check for it here.

> +               try_catch->catch(&try_catch->context);
> +               return;
> +       }
> +
> +       wake_result = wake_up_process(task_struct);
> +       if (wake_result != 0 && wake_result != 1) {

These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?

> +               kunit_err(test, "task was not woken properly: %d", wake_result);
> +               try_catch->catch(&try_catch->context);
> +       }
> +
> +       /*
> +        * TODO(brendanhiggins@google.com): We should probably have some type of
> +        * timeout here. The only question is what that timeout value should be.
> +        *
> +        * The intention has always been, at some point, to be able to label
> +        * tests with some type of size bucket (unit/small, integration/medium,
> +        * large/system/end-to-end, etc), where each size bucket would get a
> +        * default timeout value kind of like what Bazel does:
> +        * https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +        * There is still some debate to be had on exactly how we do this. (For
> +        * one, we probably want to have some sort of test runner level
> +        * timeout.)
> +        *
> +        * For more background on this topic, see:
> +        * https://mike-bland.com/2011/11/01/small-medium-large.html
> +        */
> +       wait_for_completion(&test_case_completion);

It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.

> +
> +       exit_code = try_catch->context.try_result;
> +       if (exit_code == -EFAULT)
> +               try_catch->catch(&try_catch->context);
> +       else if (exit_code == -EINTR)
> +               kunit_err(test, "wake_up_process() was never called.");

Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.

> +       else if (exit_code)
> +               kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->run = kunit_generic_run_try_catch;

Is the idea that 'run' would be anything besides
'kunit_generic_run_try_catch'? If it isn't going to be different, then
maybe it's simpler to just have a function like
kunit_generic_run_try_catch() that is called by the unit tests instead
of having to write 'try_catch->run(try_catch)' and indirect for the
basic case. Maybe I've missed the point entirely though and this is all
scaffolding for more complicated exception handling later on.

> +       try_catch->throw = kunit_generic_throw;
> +}
> +
> +void __weak kunit_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       kunit_generic_try_catch_init(try_catch);
> +}
> +
> +static void kunit_try_run_case(struct kunit_try_catch_context *context)
> +{
> +       struct kunit_try_catch_context *ctx = context;
> +       struct kunit *test = ctx->test;
> +       struct kunit_module *module = ctx->module;
> +       struct kunit_case *test_case = ctx->test_case;
> +
> +       /*
> +        * kunit_run_case_internal may encounter a fatal error; if it does, we
> +        * will jump to ENTER_HANDLER above instead of continuing normal control

Where is 'ENTER_HANDLER' above?

> +        * flow.
> +        */
>         kunit_run_case_internal(test, module, test_case);
> +       /* This line may never be reached. */
>         kunit_run_case_cleanup(test, module, test_case);
> +}

WARNING: multiple messages have this Message-ID (diff)
From: sboyd at kernel.org (Stephen Boyd)
Subject: [RFC v4 08/17] kunit: test: add support for test abort
Date: Tue, 26 Feb 2019 12:35:45 -0800	[thread overview]
Message-ID: <155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190214213729.21702-9-brendanhiggins@google.com>

Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.

Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?

For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.

> 
> Signed-off-by: Brendan Higgins <brendanhiggins at google.com>
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0000000000000..a936c041f1c8f

Could this whole file be another patch? It seems to be a test for the
try catch mechanism.

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->context.try_result = -EFAULT;
> +       complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> +       struct kunit_try_catch *try_catch = data;
>  
> +       try_catch->try(&try_catch->context);
> +
> +       complete_and_exit(try_catch->context.try_completion, 0);

The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.

> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> +       struct task_struct *task_struct;
> +       struct kunit *test = try_catch->context.test;
> +       int exit_code, wake_result;
> +       DECLARE_COMPLETION(test_case_completion);

DECLARE_COMPLETION_ONSTACK()?

> +
> +       try_catch->context.try_completion = &test_case_completion;
> +       try_catch->context.try_result = 0;
> +       task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +                                            try_catch,
> +                                            "kunit_try_catch_thread");
> +       if (IS_ERR_OR_NULL(task_struct)) {

It looks like NULL is never returned from kthread_create(), so don't
check for it here.

> +               try_catch->catch(&try_catch->context);
> +               return;
> +       }
> +
> +       wake_result = wake_up_process(task_struct);
> +       if (wake_result != 0 && wake_result != 1) {

These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?

> +               kunit_err(test, "task was not woken properly: %d", wake_result);
> +               try_catch->catch(&try_catch->context);
> +       }
> +
> +       /*
> +        * TODO(brendanhiggins at google.com): We should probably have some type of
> +        * timeout here. The only question is what that timeout value should be.
> +        *
> +        * The intention has always been, at some point, to be able to label
> +        * tests with some type of size bucket (unit/small, integration/medium,
> +        * large/system/end-to-end, etc), where each size bucket would get a
> +        * default timeout value kind of like what Bazel does:
> +        * https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +        * There is still some debate to be had on exactly how we do this. (For
> +        * one, we probably want to have some sort of test runner level
> +        * timeout.)
> +        *
> +        * For more background on this topic, see:
> +        * https://mike-bland.com/2011/11/01/small-medium-large.html
> +        */
> +       wait_for_completion(&test_case_completion);

It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.

> +
> +       exit_code = try_catch->context.try_result;
> +       if (exit_code == -EFAULT)
> +               try_catch->catch(&try_catch->context);
> +       else if (exit_code == -EINTR)
> +               kunit_err(test, "wake_up_process() was never called.");

Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.

> +       else if (exit_code)
> +               kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->run = kunit_generic_run_try_catch;

Is the idea that 'run' would be anything besides
'kunit_generic_run_try_catch'? If it isn't going to be different, then
maybe it's simpler to just have a function like
kunit_generic_run_try_catch() that is called by the unit tests instead
of having to write 'try_catch->run(try_catch)' and indirect for the
basic case. Maybe I've missed the point entirely though and this is all
scaffolding for more complicated exception handling later on.

> +       try_catch->throw = kunit_generic_throw;
> +}
> +
> +void __weak kunit_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       kunit_generic_try_catch_init(try_catch);
> +}
> +
> +static void kunit_try_run_case(struct kunit_try_catch_context *context)
> +{
> +       struct kunit_try_catch_context *ctx = context;
> +       struct kunit *test = ctx->test;
> +       struct kunit_module *module = ctx->module;
> +       struct kunit_case *test_case = ctx->test_case;
> +
> +       /*
> +        * kunit_run_case_internal may encounter a fatal error; if it does, we
> +        * will jump to ENTER_HANDLER above instead of continuing normal control

Where is 'ENTER_HANDLER' above?

> +        * flow.
> +        */
>         kunit_run_case_internal(test, module, test_case);
> +       /* This line may never be reached. */
>         kunit_run_case_cleanup(test, module, test_case);
> +}

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@kernel.org (Stephen Boyd)
Subject: [RFC v4 08/17] kunit: test: add support for test abort
Date: Tue, 26 Feb 2019 12:35:45 -0800	[thread overview]
Message-ID: <155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com> (raw)
Message-ID: <20190226203545.EzFL8LpniYUw4wTA01XhEZkQq-f06N_wm8i-PBzMqKI@z> (raw)
In-Reply-To: <20190214213729.21702-9-brendanhiggins@google.com>

Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.

Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?

For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.

> 
> Signed-off-by: Brendan Higgins <brendanhiggins at google.com>
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0000000000000..a936c041f1c8f

Could this whole file be another patch? It seems to be a test for the
try catch mechanism.

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->context.try_result = -EFAULT;
> +       complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> +       struct kunit_try_catch *try_catch = data;
>  
> +       try_catch->try(&try_catch->context);
> +
> +       complete_and_exit(try_catch->context.try_completion, 0);

The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.

> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> +       struct task_struct *task_struct;
> +       struct kunit *test = try_catch->context.test;
> +       int exit_code, wake_result;
> +       DECLARE_COMPLETION(test_case_completion);

DECLARE_COMPLETION_ONSTACK()?

> +
> +       try_catch->context.try_completion = &test_case_completion;
> +       try_catch->context.try_result = 0;
> +       task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +                                            try_catch,
> +                                            "kunit_try_catch_thread");
> +       if (IS_ERR_OR_NULL(task_struct)) {

It looks like NULL is never returned from kthread_create(), so don't
check for it here.

> +               try_catch->catch(&try_catch->context);
> +               return;
> +       }
> +
> +       wake_result = wake_up_process(task_struct);
> +       if (wake_result != 0 && wake_result != 1) {

These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?

> +               kunit_err(test, "task was not woken properly: %d", wake_result);
> +               try_catch->catch(&try_catch->context);
> +       }
> +
> +       /*
> +        * TODO(brendanhiggins at google.com): We should probably have some type of
> +        * timeout here. The only question is what that timeout value should be.
> +        *
> +        * The intention has always been, at some point, to be able to label
> +        * tests with some type of size bucket (unit/small, integration/medium,
> +        * large/system/end-to-end, etc), where each size bucket would get a
> +        * default timeout value kind of like what Bazel does:
> +        * https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +        * There is still some debate to be had on exactly how we do this. (For
> +        * one, we probably want to have some sort of test runner level
> +        * timeout.)
> +        *
> +        * For more background on this topic, see:
> +        * https://mike-bland.com/2011/11/01/small-medium-large.html
> +        */
> +       wait_for_completion(&test_case_completion);

It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.

> +
> +       exit_code = try_catch->context.try_result;
> +       if (exit_code == -EFAULT)
> +               try_catch->catch(&try_catch->context);
> +       else if (exit_code == -EINTR)
> +               kunit_err(test, "wake_up_process() was never called.");

Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.

> +       else if (exit_code)
> +               kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->run = kunit_generic_run_try_catch;

Is the idea that 'run' would be anything besides
'kunit_generic_run_try_catch'? If it isn't going to be different, then
maybe it's simpler to just have a function like
kunit_generic_run_try_catch() that is called by the unit tests instead
of having to write 'try_catch->run(try_catch)' and indirect for the
basic case. Maybe I've missed the point entirely though and this is all
scaffolding for more complicated exception handling later on.

> +       try_catch->throw = kunit_generic_throw;
> +}
> +
> +void __weak kunit_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       kunit_generic_try_catch_init(try_catch);
> +}
> +
> +static void kunit_try_run_case(struct kunit_try_catch_context *context)
> +{
> +       struct kunit_try_catch_context *ctx = context;
> +       struct kunit *test = ctx->test;
> +       struct kunit_module *module = ctx->module;
> +       struct kunit_case *test_case = ctx->test_case;
> +
> +       /*
> +        * kunit_run_case_internal may encounter a fatal error; if it does, we
> +        * will jump to ENTER_HANDLER above instead of continuing normal control

Where is 'ENTER_HANDLER' above?

> +        * flow.
> +        */
>         kunit_run_case_internal(test, module, test_case);
> +       /* This line may never be reached. */
>         kunit_run_case_cleanup(test, module, test_case);
> +}

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Brendan Higgins <brendanhiggins@google.com>,
	frowand.list@gmail.com, keescook@google.com,
	kieran.bingham@ideasonboard.com, mcgrof@kernel.org,
	robh@kernel.org, shuah@kernel.org
Cc: brakmo@fb.com, pmladek@suse.com, amir73il@gmail.com,
	Brendan Higgins <brendanhiggins@google.com>,
	dri-devel@lists.freedesktop.org, Alexander.Levin@microsoft.com,
	linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org,
	richard@nod.at, knut.omang@oracle.com, wfg@linux.intel.com,
	joel@jms.id.au, jdike@addtoit.com, dan.carpenter@oracle.com,
	devicetree@vger.kernel.org, Tim.Bird@sony.com,
	linux-um@lists.infradead.org, rostedt@goodmis.org,
	julia.lawall@lip6.fr, dan.j.williams@intel.com,
	kunit-dev@googlegroups.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, daniel@ffwll.ch,
	mpe@ellerman.id.au, joe@perches.com, khilman@baylibre.com
Subject: Re: [RFC v4 08/17] kunit: test: add support for test abort
Date: Tue, 26 Feb 2019 12:35:45 -0800	[thread overview]
Message-ID: <155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190214213729.21702-9-brendanhiggins@google.com>

Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.

Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?

For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.

> 
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0000000000000..a936c041f1c8f

Could this whole file be another patch? It seems to be a test for the
try catch mechanism.

> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->context.try_result = -EFAULT;
> +       complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> +       struct kunit_try_catch *try_catch = data;
>  
> +       try_catch->try(&try_catch->context);
> +
> +       complete_and_exit(try_catch->context.try_completion, 0);

The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.

> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> +       struct task_struct *task_struct;
> +       struct kunit *test = try_catch->context.test;
> +       int exit_code, wake_result;
> +       DECLARE_COMPLETION(test_case_completion);

DECLARE_COMPLETION_ONSTACK()?

> +
> +       try_catch->context.try_completion = &test_case_completion;
> +       try_catch->context.try_result = 0;
> +       task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +                                            try_catch,
> +                                            "kunit_try_catch_thread");
> +       if (IS_ERR_OR_NULL(task_struct)) {

It looks like NULL is never returned from kthread_create(), so don't
check for it here.

> +               try_catch->catch(&try_catch->context);
> +               return;
> +       }
> +
> +       wake_result = wake_up_process(task_struct);
> +       if (wake_result != 0 && wake_result != 1) {

These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?

> +               kunit_err(test, "task was not woken properly: %d", wake_result);
> +               try_catch->catch(&try_catch->context);
> +       }
> +
> +       /*
> +        * TODO(brendanhiggins@google.com): We should probably have some type of
> +        * timeout here. The only question is what that timeout value should be.
> +        *
> +        * The intention has always been, at some point, to be able to label
> +        * tests with some type of size bucket (unit/small, integration/medium,
> +        * large/system/end-to-end, etc), where each size bucket would get a
> +        * default timeout value kind of like what Bazel does:
> +        * https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +        * There is still some debate to be had on exactly how we do this. (For
> +        * one, we probably want to have some sort of test runner level
> +        * timeout.)
> +        *
> +        * For more background on this topic, see:
> +        * https://mike-bland.com/2011/11/01/small-medium-large.html
> +        */
> +       wait_for_completion(&test_case_completion);

It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.

> +
> +       exit_code = try_catch->context.try_result;
> +       if (exit_code == -EFAULT)
> +               try_catch->catch(&try_catch->context);
> +       else if (exit_code == -EINTR)
> +               kunit_err(test, "wake_up_process() was never called.");

Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.

> +       else if (exit_code)
> +               kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       try_catch->run = kunit_generic_run_try_catch;

Is the idea that 'run' would be anything besides
'kunit_generic_run_try_catch'? If it isn't going to be different, then
maybe it's simpler to just have a function like
kunit_generic_run_try_catch() that is called by the unit tests instead
of having to write 'try_catch->run(try_catch)' and indirect for the
basic case. Maybe I've missed the point entirely though and this is all
scaffolding for more complicated exception handling later on.

> +       try_catch->throw = kunit_generic_throw;
> +}
> +
> +void __weak kunit_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> +       kunit_generic_try_catch_init(try_catch);
> +}
> +
> +static void kunit_try_run_case(struct kunit_try_catch_context *context)
> +{
> +       struct kunit_try_catch_context *ctx = context;
> +       struct kunit *test = ctx->test;
> +       struct kunit_module *module = ctx->module;
> +       struct kunit_case *test_case = ctx->test_case;
> +
> +       /*
> +        * kunit_run_case_internal may encounter a fatal error; if it does, we
> +        * will jump to ENTER_HANDLER above instead of continuing normal control

Where is 'ENTER_HANDLER' above?

> +        * flow.
> +        */
>         kunit_run_case_internal(test, module, test_case);
> +       /* This line may never be reached. */
>         kunit_run_case_cleanup(test, module, test_case);
> +}

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  parent reply	other threads:[~2019-02-26 20:35 UTC|newest]

Thread overview: 316+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 21:37 [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` [RFC v4 02/17] kunit: test: add test resource management API Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` brendanhiggins
2019-02-15 21:01   ` Stephen Boyd
2019-02-15 21:01     ` Stephen Boyd
2019-02-15 21:01     ` Stephen Boyd
2019-02-15 21:01     ` sboyd
2019-02-15 21:01     ` Stephen Boyd
2019-02-19 23:24     ` Brendan Higgins
2019-02-19 23:24       ` Brendan Higgins
2019-02-19 23:24       ` Brendan Higgins
2019-02-19 23:24       ` brendanhiggins
2019-02-19 23:24       ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 07/17] kunit: test: add initial tests Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` brendanhiggins
2019-02-14 21:37 ` [RFC v4 16/17] of: unittest: split out a couple of test cases from unittest Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` brendanhiggins
2019-03-22  1:14   ` Frank Rowand
2019-03-22  1:14     ` Frank Rowand
2019-03-22  1:14     ` Frank Rowand
2019-03-22  1:14     ` frowand.list
2019-03-22  1:14     ` Frank Rowand
2019-03-22  1:45     ` Brendan Higgins
2019-03-22  1:45       ` Brendan Higgins
2019-03-22  1:45       ` Brendan Higgins
2019-03-22  1:45       ` brendanhiggins
2019-03-22  1:45       ` Brendan Higgins
2019-03-22  1:45       ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 17/17] of: unittest: split up some super large test cases Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` Brendan Higgins
2019-02-14 21:37   ` brendanhiggins
2019-03-22  1:16   ` Frank Rowand
2019-03-22  1:16     ` Frank Rowand
2019-03-22  1:16     ` Frank Rowand
2019-03-22  1:16     ` frowand.list
2019-03-22  1:16     ` Frank Rowand
2019-03-22  1:16     ` Frank Rowand
     [not found]     ` <09b06e6d-fd36-707e-cb7a-e935bd930510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-22  1:45       ` Brendan Higgins
2019-03-22  1:45         ` Brendan Higgins
2019-03-22  1:45         ` Brendan Higgins
2019-03-22  1:45         ` brendanhiggins
2019-03-22  1:45         ` Brendan Higgins
2019-02-18 20:02 ` [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Frank Rowand
2019-02-18 20:02   ` Frank Rowand
2019-02-18 20:02   ` Frank Rowand
2019-02-18 20:02   ` frowand.list
2019-02-20  6:34   ` Brendan Higgins
2019-02-20  6:34     ` Brendan Higgins
2019-02-20  6:34     ` Brendan Higgins
2019-02-20  6:34     ` brendanhiggins
2019-02-20  6:34     ` Brendan Higgins
2019-02-20  6:46     ` Frank Rowand
2019-02-20  6:46       ` Frank Rowand
2019-02-20  6:46       ` Frank Rowand
2019-02-20  6:46       ` frowand.list
2019-02-20  6:46       ` Frank Rowand
2019-02-22 20:52       ` Thiago Jung Bauermann
2019-02-22 20:52         ` Thiago Jung Bauermann
2019-02-22 20:52         ` Thiago Jung Bauermann
2019-02-22 20:52         ` bauerman
2019-02-22 20:52         ` Thiago Jung Bauermann
2019-02-28  4:18         ` Brendan Higgins
2019-02-28  4:18           ` Brendan Higgins
2019-02-28  4:18           ` brendanhiggins
2019-02-28  4:18           ` Brendan Higgins
2019-02-28  4:15       ` Brendan Higgins
2019-02-28  4:15         ` Brendan Higgins
2019-02-28  4:15         ` Brendan Higgins
2019-02-28  4:15         ` brendanhiggins
2019-02-28  4:15         ` Brendan Higgins
2019-03-04 23:01 ` Brendan Higgins
2019-03-04 23:01   ` Brendan Higgins
2019-03-04 23:01   ` Brendan Higgins
2019-03-04 23:01   ` brendanhiggins
2019-03-04 23:01   ` Brendan Higgins
2019-03-22  1:23   ` Frank Rowand
2019-03-22  1:23     ` Frank Rowand
2019-03-22  1:23     ` Frank Rowand
2019-03-22  1:23     ` frowand.list
2019-03-22  1:23     ` Frank Rowand
2019-03-22  1:23     ` Frank Rowand
     [not found]     ` <0e6eb370-3e62-e1a5-1b91-bccc5868e8e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-25 22:11       ` Brendan Higgins
2019-03-25 22:11         ` Brendan Higgins
2019-03-25 22:11         ` Brendan Higgins
2019-03-25 22:11         ` brendanhiggins
2019-03-25 22:11         ` Brendan Higgins
     [not found] ` <20190214213729.21702-1-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-14 21:37   ` [RFC v4 01/17] kunit: test: add KUnit test runner core Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 03/17] kunit: test: add string_stream a std::stream like string builder Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 04/17] kunit: test: add test_stream a std::stream like logger Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 05/17] kunit: test: add the concept of expectations Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 06/17] kbuild: enable building KUnit Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 08/17] kunit: test: add support for test abort Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
     [not found]     ` <20190214213729.21702-9-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-18 19:52       ` Frank Rowand
2019-02-18 19:52         ` Frank Rowand
2019-02-18 19:52         ` frowand.list
2019-02-18 19:52         ` Frank Rowand
     [not found]         ` <da1995fa-a362-dfe6-8184-7fcdf2b923e8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-20  3:39           ` Brendan Higgins
2019-02-20  3:39             ` Brendan Higgins
2019-02-20  3:39             ` Brendan Higgins
2019-02-20  3:39             ` brendanhiggins
2019-02-20  3:39             ` Brendan Higgins
2019-02-20  6:44             ` Frank Rowand
2019-02-20  6:44               ` Frank Rowand
2019-02-20  6:44               ` Frank Rowand
2019-02-20  6:44               ` frowand.list
2019-02-20  6:44               ` Frank Rowand
2019-02-20  6:44               ` Frank Rowand
2019-02-28  7:42               ` Brendan Higgins
2019-02-28  7:42                 ` Brendan Higgins
2019-02-28  7:42                 ` Brendan Higgins
2019-02-28  7:42                 ` brendanhiggins
2019-02-28  7:42                 ` Brendan Higgins
     [not found]                 ` <CAFd5g47EDmsBWKNiW0jpHW2VG_GWCfe8UO+=ofgM2_ru+_UBQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22  1:09                   ` Frank Rowand
2019-03-22  1:09                     ` Frank Rowand
2019-03-22  1:09                     ` Frank Rowand
2019-03-22  1:09                     ` frowand.list
2019-03-22  1:09                     ` Frank Rowand
2019-03-22  1:41                     ` Brendan Higgins
2019-03-22  1:41                       ` Brendan Higgins
2019-03-22  1:41                       ` Brendan Higgins
2019-03-22  1:41                       ` brendanhiggins
2019-03-22  1:41                       ` Brendan Higgins
     [not found]                       ` <CAFd5g46AP9yZQ+z+60HGaZuqhJQmfSBw9+r62w4k=cGiMEkqLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22  7:10                         ` Knut Omang
2019-03-22  7:10                           ` Knut Omang
2019-03-22  7:10                           ` Knut Omang
2019-03-22  7:10                           ` knut.omang
2019-03-22  7:10                           ` Knut Omang
2019-03-25 22:32                           ` Brendan Higgins
2019-03-25 22:32                             ` Brendan Higgins
2019-03-25 22:32                             ` brendanhiggins
2019-03-25 22:32                             ` Brendan Higgins
     [not found]                             ` <CAFd5g44eqjN-nVCJuoeYFCxwVa5AorWiAnXe-tFCAc11zDgJFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-26  7:44                               ` Knut Omang
2019-03-26  7:44                                 ` Knut Omang
2019-03-26  7:44                                 ` Knut Omang
2019-03-26  7:44                                 ` knut.omang
2019-03-26  7:44                                 ` Knut Omang
2019-02-26 20:35       ` Stephen Boyd [this message]
2019-02-26 20:35         ` Stephen Boyd
2019-02-26 20:35         ` Stephen Boyd
2019-02-26 20:35         ` sboyd
2019-02-26 20:35         ` Stephen Boyd
     [not found]         ` <155121334527.260864.5324117081460979741-n1Xw8LXHxjTHt/MElyovVYaSKrA+ACpX0E9HWUfgJXw@public.gmane.org>
2019-02-28  9:03           ` Brendan Higgins
2019-02-28  9:03             ` Brendan Higgins
2019-02-28  9:03             ` brendanhiggins
2019-02-28  9:03             ` Brendan Higgins
2019-02-28 13:54             ` Dan Carpenter
2019-02-28 13:54               ` Dan Carpenter
2019-02-28 13:54               ` Dan Carpenter
2019-02-28 13:54               ` dan.carpenter
2019-02-28 13:54               ` Dan Carpenter
2019-03-04 22:28               ` Brendan Higgins
2019-03-04 22:28                 ` Brendan Higgins
2019-03-04 22:28                 ` Brendan Higgins
2019-03-04 22:28                 ` brendanhiggins
2019-03-04 22:28                 ` Brendan Higgins
2019-02-28 18:02             ` Stephen Boyd
2019-02-28 18:02               ` Stephen Boyd
     [not found]               ` <155137694423.260864.2846034318906225490-n1Xw8LXHxjTHt/MElyovVYaSKrA+ACpX0E9HWUfgJXw@public.gmane.org>
2019-03-04 22:39                 ` Brendan Higgins
2019-03-04 22:39                   ` Brendan Higgins
2019-03-04 22:39                   ` Brendan Higgins
2019-03-04 22:39                   ` brendanhiggins
2019-03-04 22:39                   ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 09/17] kunit: test: add the concept of assertions Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 10/17] kunit: test: add test managed resource tests Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
     [not found]     ` <20190214213729.21702-11-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-15 20:54       ` Stephen Boyd
2019-02-15 20:54         ` Stephen Boyd
2019-02-15 20:54         ` Stephen Boyd
2019-02-15 20:54         ` sboyd
2019-02-15 20:54         ` Stephen Boyd
2019-02-19 23:20         ` Brendan Higgins
2019-02-19 23:20           ` Brendan Higgins
2019-02-19 23:20           ` Brendan Higgins
2019-02-19 23:20           ` brendanhiggins
2019-02-19 23:20           ` Brendan Higgins
2019-02-20 22:03           ` Stephen Boyd
2019-02-20 22:03             ` Stephen Boyd
2019-02-14 21:37   ` [RFC v4 11/17] kunit: tool: add Python wrappers for running KUnit tests Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 12/17] kunit: defconfig: add defconfigs for building " Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 13/17] Documentation: kunit: add documentation for KUnit Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 14/17] MAINTAINERS: add entry for KUnit the unit testing framework Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37   ` [RFC v4 15/17] of: unittest: migrate tests to run on KUnit Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` Brendan Higgins
2019-02-14 21:37     ` brendanhiggins
2019-02-14 21:37     ` Brendan Higgins
     [not found]     ` <20190214213729.21702-16-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-16  0:24       ` Frank Rowand
2019-02-16  0:24         ` Frank Rowand
2019-02-16  0:24         ` Frank Rowand
2019-02-16  0:24         ` frowand.list
2019-02-16  0:24         ` Frank Rowand
     [not found]         ` <cda7c8db-a6d0-6a93-5c33-9ccf32dfd29a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-20  2:24           ` Brendan Higgins
2019-02-20  2:24             ` Brendan Higgins
2019-02-20  2:24             ` Brendan Higgins
2019-02-20  2:24             ` brendanhiggins
2019-02-20  2:24             ` Brendan Higgins
2019-03-21  1:07   ` [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Logan Gunthorpe
2019-03-21  1:07     ` Logan Gunthorpe
2019-03-21  1:07     ` Logan Gunthorpe
2019-03-21  1:07     ` logang
2019-03-21  1:07     ` Logan Gunthorpe
     [not found]     ` <6d9b3b21-1179-3a45-7545-30aa15306cb4-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21  5:23       ` Knut Omang
2019-03-21  5:23         ` Knut Omang
2019-03-21  5:23         ` Knut Omang
2019-03-21  5:23         ` knut.omang
2019-03-21  5:23         ` Knut Omang
2019-03-21 15:56         ` Logan Gunthorpe
2019-03-21 15:56           ` Logan Gunthorpe
2019-03-21 15:56           ` Logan Gunthorpe
2019-03-21 15:56           ` logang
2019-03-21 15:56           ` Logan Gunthorpe
2019-03-21 15:56           ` Logan Gunthorpe
     [not found]           ` <ce355f5c-189c-816c-cde4-fb4e816d44e7-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21 16:55             ` Brendan Higgins
2019-03-21 16:55               ` Brendan Higgins
2019-03-21 16:55               ` Brendan Higgins
2019-03-21 16:55               ` brendanhiggins
2019-03-21 16:55               ` Brendan Higgins
     [not found]               ` <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-21 19:13                 ` Knut Omang
2019-03-21 19:13                   ` Knut Omang
2019-03-21 19:13                   ` Knut Omang
2019-03-21 19:13                   ` knut.omang
2019-03-21 19:13                   ` Knut Omang
2019-03-21 19:29                   ` Logan Gunthorpe
2019-03-21 19:29                     ` Logan Gunthorpe
2019-03-21 19:29                     ` Logan Gunthorpe
2019-03-21 19:29                     ` logang
2019-03-21 19:29                     ` Logan Gunthorpe
2019-03-21 19:29                     ` Logan Gunthorpe
     [not found]                     ` <961494a3-d08c-2720-c59d-7d7008edb288-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21 20:14                       ` Knut Omang
2019-03-21 20:14                         ` Knut Omang
2019-03-21 20:14                         ` Knut Omang
2019-03-21 20:14                         ` knut.omang
2019-03-21 20:14                         ` Knut Omang
2019-03-21 22:07       ` Brendan Higgins
2019-03-21 22:07         ` Brendan Higgins
2019-03-21 22:07         ` Brendan Higgins
2019-03-21 22:07         ` brendanhiggins
2019-03-21 22:07         ` Brendan Higgins
2019-03-21 22:26         ` Logan Gunthorpe
2019-03-21 22:26           ` Logan Gunthorpe
2019-03-21 22:26           ` Logan Gunthorpe
2019-03-21 22:26           ` logang
2019-03-21 22:26           ` Logan Gunthorpe
2019-03-21 23:33           ` Brendan Higgins
2019-03-21 23:33             ` Brendan Higgins
2019-03-21 23:33             ` Brendan Higgins
2019-03-21 23:33             ` brendanhiggins
2019-03-21 23:33             ` Brendan Higgins
2019-03-22  1:12             ` Frank Rowand
2019-03-22  1:12               ` Frank Rowand
2019-03-22  1:12               ` Frank Rowand
2019-03-22  1:12               ` frowand.list
2019-03-22  1:12               ` Frank Rowand
2019-03-22  1:12               ` Frank Rowand
     [not found]               ` <aea24c8e-5ce8-5f33-c81b-d2eeef588ec8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-25 22:12                 ` Brendan Higgins
2019-03-25 22:12                   ` Brendan Higgins
2019-03-25 22:12                   ` Brendan Higgins
2019-03-25 22:12                   ` brendanhiggins
2019-03-25 22:12                   ` Brendan Higgins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=155121334527.260864.5324117081460979741@swboyd.mtv.corp.google.com \
    --to=sboyd-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=Alexander.Levin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org \
    --cc=Tim.Bird-7U/KSKJipcs@public.gmane.org \
    --cc=amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=brakmo-b10kYP2dOMg@public.gmane.org \
    --cc=brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=daniel-/w4YWyX8dFk@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org \
    --cc=joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org \
    --cc=joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org \
    --cc=julia.lawall-L2FTfq7BK8M@public.gmane.org \
    --cc=keescook-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org \
    --cc=pmladek-IBi9RG/b67k@public.gmane.org \
    --cc=richard-/L3Ra7n9ekc@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
    --cc=shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.