[net-next,0/3] add skb_segment kunit coverage

Message

Willem de Bruijn Oct. 5, 2023, 1:48 p.m. UTC

From: Willem de Bruijn <[e-mail]>

As discussed at netconf last week. Some kernel code is exercised in
many different ways. skb_segment is a prime example. This ~350 line
function has 49 different patches in git blame with 28 different
authors.

When making a change, e.g., to fix a bug in one specific use case,
it is hard to establish through analysis alone that the change does
not break the many other paths through the code. It is impractical to
exercise all code paths through regression testing from userspace.

Add the minimal infrastructure needed to add KUnit tests to networking,
and add code coverage for this function.

Patch 1 adds the infra and the first simple test case: a linear skb
Patch 2 adds variants with frags[]
Patch 3 adds variants with frag_list skbs

Willem de Bruijn (3):
  net: add skb_segment kunit test
  net: parametrize skb_segment unit test to expand coverage
  net: expand skb_segment unit test with frag_list coverage

 net/Kconfig         |   9 ++
 net/core/Makefile   |   1 +
 net/core/gso_test.c | 274 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 284 insertions(+)
 create mode 100644 net/core/gso_test.c

Comments

Florian Westphal Oct. 6, 2023, 10:14 p.m. UTC | #1

Willem de Bruijn <[e-mail]> wrote:
> As discussed at netconf last week. Some kernel code is exercised in
> many different ways. skb_segment is a prime example. This ~350 line
> function has 49 different patches in git blame with 28 different
> authors.

Thanks for this work, and especially for adding commit ids
for relevant features that are tested.

Reviewed-by: Florian Westphal <[e-mail]>

Jakub Kicinski Oct. 7, 2023, 12:30 a.m. UTC | #2

On Thu,  5 Oct 2023 09:48:54 -0400 Willem de Bruijn wrote:
> As discussed at netconf last week. Some kernel code is exercised in
> many different ways. skb_segment is a prime example. This ~350 line
> function has 49 different patches in git blame with 28 different
> authors.
> 
> When making a change, e.g., to fix a bug in one specific use case,
> it is hard to establish through analysis alone that the change does
> not break the many other paths through the code. It is impractical to
> exercise all code paths through regression testing from userspace.
> 
> Add the minimal infrastructure needed to add KUnit tests to networking,
> and add code coverage for this function.

Apparently we're supposed add descriptions to all modules now:

WARNING: modpost: missing MODULE_DESCRIPTION() in net/core/gso_test.o

Willem de Bruijn Oct. 7, 2023, 9:02 a.m. UTC | #3

On Fri, Oct 6, 2023 at 7:30 PM Jakub Kicinski <[e-mail]> wrote:
>
> On Thu,  5 Oct 2023 09:48:54 -0400 Willem de Bruijn wrote:
> > As discussed at netconf last week. Some kernel code is exercised in
> > many different ways. skb_segment is a prime example. This ~350 line
> > function has 49 different patches in git blame with 28 different
> > authors.
> >
> > When making a change, e.g., to fix a bug in one specific use case,
> > it is hard to establish through analysis alone that the change does
> > not break the many other paths through the code. It is impractical to
> > exercise all code paths through regression testing from userspace.
> >
> > Add the minimal infrastructure needed to add KUnit tests to networking,
> > and add code coverage for this function.
>
> Apparently we're supposed add descriptions to all modules now:
>
> WARNING: modpost: missing MODULE_DESCRIPTION() in net/core/gso_test.o

Will fix and resend. Thanks.