mbox series

[v1,0/3] kunit: Deferred action helpers

Message ID 20230421084226.2278282-1-davidgow@google.com
Headers show
Series kunit: Deferred action helpers | expand

Message

David Gow April 21, 2023, 8:42 a.m. UTC
This is v1 of the KUnit deferred actions API, which implements an
equivalent of devm_add_action[1] on top of KUnit managed resources. This
provides a simple way of scheduling a function to run when the test
terminates (whether successfully, or with an error). It's therefore very
useful for freeing resources, or otherwise cleaning up.

The notable changes since RFCv2[2] are:
- Got rid of the 'cancellation token' concept. It was overcomplicated,
  and we can add it back if we need to.
- kunit_add_action() therefore now returns 0 on success, and an error
  otherwise (like devm_add_action()). Though you may wish to use:
- Added kunit_add_action_or_reset(), which will call the deferred
  function if an error occurs. (See devm_add_action_or_reset()). This
  also returns an error on failure, which can be asserted safely.
- Got rid of the function pointer typedef. Personally, I liked it, but
  it's more typedef-y than most kernel code.
- Got rid of the 'internal_gfp' argument: all internal state is now
  allocated with GFP_KERNEL. The main KUnit resource API can be used
  instead if this doesn't work for your use-case.

I'd love to hear any further thoughts!

Cheers,
-- David

[1]: https://docs.kernel.org/driver-api/basics.html#c.devm_add_action
[2]: https://patchwork.kernel.org/project/linux-kselftest/list/?series=735720


David Gow (3):
  kunit: Add kunit_add_action() to defer a call until test exit
  kunit: executor_test: Use kunit_add_action()
  kunit: kmalloc_array: Use kunit_add_action()

 include/kunit/resource.h  | 76 +++++++++++++++++++++++++++++++
 include/kunit/test.h      | 10 ++++-
 lib/kunit/executor_test.c | 11 ++---
 lib/kunit/kunit-test.c    | 88 +++++++++++++++++++++++++++++++++++-
 lib/kunit/resource.c      | 95 +++++++++++++++++++++++++++++++++++++++
 lib/kunit/test.c          | 48 ++++----------------
 6 files changed, 279 insertions(+), 49 deletions(-)

Comments

Benjamin Berg April 24, 2023, 2:02 p.m. UTC | #1
Hi David,

On Mon, 2023-04-24 at 14:32 +0200, Benjamin Berg wrote:
> On Fri, 2023-04-21 at 16:42 +0800, 'David Gow' via KUnit Development wrote:
> > This is v1 of the KUnit deferred actions API, which implements an
> > equivalent of devm_add_action[1] on top of KUnit managed resources. This
> > provides a simple way of scheduling a function to run when the test
> > terminates (whether successfully, or with an error). It's therefore very
> > useful for freeing resources, or otherwise cleaning up.
> > 
> > The notable changes since RFCv2[2] are:
> > - Got rid of the 'cancellation token' concept. It was overcomplicated,
> >   and we can add it back if we need to.
> > - kunit_add_action() therefore now returns 0 on success, and an error
> >   otherwise (like devm_add_action()). Though you may wish to use:
> > - Added kunit_add_action_or_reset(), which will call the deferred
> >   function if an error occurs. (See devm_add_action_or_reset()). This
> >   also returns an error on failure, which can be asserted safely.
> > - Got rid of the function pointer typedef. Personally, I liked it, but
> >   it's more typedef-y than most kernel code.
> > - Got rid of the 'internal_gfp' argument: all internal state is now
> >   allocated with GFP_KERNEL. The main KUnit resource API can be used
> >   instead if this doesn't work for your use-case.
> > 
> > I'd love to hear any further thoughts!
> 
> I am happy with it as-is.

Oh, wait. Nothing big, but I just noticed that the new API functions
seem to not yet be exported using EXPORT_SYMBOL_GPL.

Benjamin

> Reviewed-By: Benjamin Berg <benjamin.berg@intel.com>
> 
> > 
> > Cheers,
> > -- David
> > 
> > [1]:
> > https://docs.kernel.org/driver-api/basics.html#c.devm_add_action
> > [2]:
> > https://patchwork.kernel.org/project/linux-kselftest/list/?series=735720
> > 
> > 
> > David Gow (3):
> >   kunit: Add kunit_add_action() to defer a call until test exit
> >   kunit: executor_test: Use kunit_add_action()
> >   kunit: kmalloc_array: Use kunit_add_action()
> > 
> >  include/kunit/resource.h  | 76 +++++++++++++++++++++++++++++++
> >  include/kunit/test.h      | 10 ++++-
> >  lib/kunit/executor_test.c | 11 ++---
> >  lib/kunit/kunit-test.c    | 88
> > +++++++++++++++++++++++++++++++++++-
> >  lib/kunit/resource.c      | 95
> > +++++++++++++++++++++++++++++++++++++++
> >  lib/kunit/test.c          | 48 ++++----------------
> >  6 files changed, 279 insertions(+), 49 deletions(-)
> > 
> > -- 
> > 2.40.0.634.g4ca3ef3211-goog
> > 
>
Maxime Ripard April 25, 2023, 3:23 p.m. UTC | #2
Hi,

On Fri, Apr 21, 2023 at 04:42:23PM +0800, David Gow wrote:
> This is v1 of the KUnit deferred actions API, which implements an
> equivalent of devm_add_action[1] on top of KUnit managed resources. This
> provides a simple way of scheduling a function to run when the test
> terminates (whether successfully, or with an error). It's therefore very
> useful for freeing resources, or otherwise cleaning up.
> 
> The notable changes since RFCv2[2] are:
> - Got rid of the 'cancellation token' concept. It was overcomplicated,
>   and we can add it back if we need to.
> - kunit_add_action() therefore now returns 0 on success, and an error
>   otherwise (like devm_add_action()). Though you may wish to use:
> - Added kunit_add_action_or_reset(), which will call the deferred
>   function if an error occurs. (See devm_add_action_or_reset()). This
>   also returns an error on failure, which can be asserted safely.
> - Got rid of the function pointer typedef. Personally, I liked it, but
>   it's more typedef-y than most kernel code.
> - Got rid of the 'internal_gfp' argument: all internal state is now
>   allocated with GFP_KERNEL. The main KUnit resource API can be used
>   instead if this doesn't work for your use-case.
> 
> I'd love to hear any further thoughts!

I've converted the KMS kunit tests to use that API when relevant, and
it works like a charm and is super usable, thanks so much.

One improvement we could do as a second step is to provide a
kunit_action_t type or something to make casting kfree-like functions
easier, but it's already great overall.

Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>

Thanks again,
Maxime
David Gow April 26, 2023, 6:51 a.m. UTC | #3
On Mon, 24 Apr 2023 at 22:02, Benjamin Berg <benjamin@sipsolutions.net> wrote:
>
> Hi David,
>
> On Mon, 2023-04-24 at 14:32 +0200, Benjamin Berg wrote:
> > On Fri, 2023-04-21 at 16:42 +0800, 'David Gow' via KUnit Development wrote:
> > > This is v1 of the KUnit deferred actions API, which implements an
> > > equivalent of devm_add_action[1] on top of KUnit managed resources. This
> > > provides a simple way of scheduling a function to run when the test
> > > terminates (whether successfully, or with an error). It's therefore very
> > > useful for freeing resources, or otherwise cleaning up.
> > >
> > > The notable changes since RFCv2[2] are:
> > > - Got rid of the 'cancellation token' concept. It was overcomplicated,
> > >   and we can add it back if we need to.
> > > - kunit_add_action() therefore now returns 0 on success, and an error
> > >   otherwise (like devm_add_action()). Though you may wish to use:
> > > - Added kunit_add_action_or_reset(), which will call the deferred
> > >   function if an error occurs. (See devm_add_action_or_reset()). This
> > >   also returns an error on failure, which can be asserted safely.
> > > - Got rid of the function pointer typedef. Personally, I liked it, but
> > >   it's more typedef-y than most kernel code.
> > > - Got rid of the 'internal_gfp' argument: all internal state is now
> > >   allocated with GFP_KERNEL. The main KUnit resource API can be used
> > >   instead if this doesn't work for your use-case.
> > >
> > > I'd love to hear any further thoughts!
> >
> > I am happy with it as-is.
>
> Oh, wait. Nothing big, but I just noticed that the new API functions
> seem to not yet be exported using EXPORT_SYMBOL_GPL.

Ah, nice catch! I'll add those to the next version.

Cheers,
-- David
David Gow April 26, 2023, 6:51 a.m. UTC | #4
On Tue, 25 Apr 2023 at 23:23, Maxime Ripard <maxime@cerno.tech> wrote:
>
> Hi,
>
> On Fri, Apr 21, 2023 at 04:42:23PM +0800, David Gow wrote:
> > This is v1 of the KUnit deferred actions API, which implements an
> > equivalent of devm_add_action[1] on top of KUnit managed resources. This
> > provides a simple way of scheduling a function to run when the test
> > terminates (whether successfully, or with an error). It's therefore very
> > useful for freeing resources, or otherwise cleaning up.
> >
> > The notable changes since RFCv2[2] are:
> > - Got rid of the 'cancellation token' concept. It was overcomplicated,
> >   and we can add it back if we need to.
> > - kunit_add_action() therefore now returns 0 on success, and an error
> >   otherwise (like devm_add_action()). Though you may wish to use:
> > - Added kunit_add_action_or_reset(), which will call the deferred
> >   function if an error occurs. (See devm_add_action_or_reset()). This
> >   also returns an error on failure, which can be asserted safely.
> > - Got rid of the function pointer typedef. Personally, I liked it, but
> >   it's more typedef-y than most kernel code.
> > - Got rid of the 'internal_gfp' argument: all internal state is now
> >   allocated with GFP_KERNEL. The main KUnit resource API can be used
> >   instead if this doesn't work for your use-case.
> >
> > I'd love to hear any further thoughts!
>
> I've converted the KMS kunit tests to use that API when relevant, and
> it works like a charm and is super usable, thanks so much.

Nice! I'm glad it's working well.
>
> One improvement we could do as a second step is to provide a
> kunit_action_t type or something to make casting kfree-like functions
> easier, but it's already great overall.

I had that in an earlier version and got rid of it to better match
what devm_* was doing, but I personally agree that it's nice to have.
I'll add it back in the next version.

> Reviewed-by: Maxime Ripard <maxime@cerno.tech>
> Tested-by: Maxime Ripard <maxime@cerno.tech>


Cheers,
-- David