[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231008201244.3700784-1-willemdebruijn.kernel@gmail.com>
Date: Sun, 8 Oct 2023 16:12:31 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: netdev@...r.kernel.org
Cc: davem@...emloft.net,
kuba@...nel.org,
edumazet@...gle.com,
pabeni@...hat.com,
alexander.duyck@...il.com,
fw@...len.de,
Willem de Bruijn <willemb@...gle.com>
Subject: [PATCH net-next v2 0/3] add skb_segment kunit coverage
From: Willem de Bruijn <willemb@...gle.com>
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
Changes v1->v2 in the individual patches.
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
--
2.42.0.609.gbb76f46606-goog
Powered by blists - more mailing lists