LKML Archive on
 help / Atom feed
From: Rafael David Tinoco <>
To: Shuah Khan <>
Cc: Rafael David Tinoco <>,
	"David S. Miller" <>,,,,
	Willem de Bruijn <>,
	Dan Rue <>,
	Anders Roxell <>
Subject: selftests/net: udpgso: LTS kernels supportability ?
Date: Mon, 17 Dec 2018 15:53:07 -0200
Message-ID: <> (raw)


I was recently investigating some errors coming out of our functional
tests and we, Dan and I, came up with a discussion that might not be new
for you, but, interests us, in defining how to better use kselftests as
a regression mechanism/tool in our LKFT (

David / Willem,

I'm only using udpgso as an example for what I'd like to ask Shuah. Feel
free to jump in in the discussion if you think its worth.


Regarding: udpgso AND

udpgso tests are failing in kernels bellow 4.18 because of 2 main reasons:

1) udp4_ufo_fragment does not seem to demand the GSO SKB to be > than
the MTU for older kernels (4th test case in udpgso.c).

2) setsockopt(...UDP_SEGMENT) support is not present for older kernels.
(commits "udp: generate gso with UDP_SEGMENT" and its fixes seem to be

With that explained, finally the question/discussion:

Shouldn't we enforce a versioning mechanism for tests that are testing
recently added features ? I mean, some of the tests inside udpgso
selftest are good enough for older kernels...

But, because we have no control over "kernel features" and "supported
test cases", we, Linaro, have to end up blacklisting all selftests that
have new feature oriented tests, because one or two test cases only.

This has already been solved in other functional tests projects:
allowing to check the running kernel version and deciding which test
cases to run.

Would that be something we should pursue ? (We could try to make patches
here and there, like this case, whenever we face this). Or... should we
stick with mainline/next only when talking about kselftest and forget
about LTS kernels ?

OBS: Situations like this are very time consuming before we can tell if
there was a regression or the older kernel did not support the test case.

Thank you for the attention.

Rafael D. Tinoco
Linaro - Kernel Validation

             reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 17:53 Rafael David Tinoco [this message]
2018-12-17 18:42 ` shuah
2018-12-18 11:37   ` Rafael David Tinoco
2018-12-18 14:53     ` shuah
2018-12-18 15:36       ` Rafael David Tinoco

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox