netdev - RE: [PATCH net-next v4 0/9] Create common DPLL configuration API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR11MB4657374BF0A9361647444D239B1BA@DM6PR11MB4657.namprd11.prod.outlook.com>
Date: Fri, 18 Aug 2023 10:15:34 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
CC: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Jonathan Lemon
	<jonathan.lemon@...il.com>, Paolo Abeni <pabeni@...hat.com>, "Olech, Milena"
	<milena.olech@...el.com>, "Michalik, Michal" <michal.michalik@...el.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, poros <poros@...hat.com>, mschmidt
	<mschmidt@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>, Bart Van Assche
	<bvanassche@....org>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>
Subject: RE: [PATCH net-next v4 0/9] Create common DPLL configuration API

>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Tuesday, August 15, 2023 7:02 PM
>
>On Tue, 15 Aug 2023 13:52:10 +0200 Jiri Pirko wrote:
>> >> Feels like we're lacking tests here. Is there a common subset of
>> >> stuff we can expect reasonable devices to support?
>> >> Anything you used in development that can be turned into tests?
>> >
>> >Well, we were playing with the tool ynl/cli.py and it's stated in
>> >the cover letter. But needs proper hardware to run. I'm not sure
>> >we can easily create emulation device to run tests.
>>
>> Well, something like "dpllsim", similar to netdevsim would be certainly
>> possible, then you can use it to write selftests for the uapi testing.
>> But why don't we do that as a follow-up patchset?
>
>I was thinking about a test that can be run against real HW.
>Something that a new vendor implementing DPLL can run and
>validate that their implementation behaves as expected.
>And something that distributors and stable kernels could
>potentially use to validate the code still works.
>
>We don't have any well established user space to make use of this
>new functionality, there's high risk that drivers will invent their
>own ways of interpreting the API.
>
>Perhaps something that Red Hat could help with? I'm guessing you'd
>be writing test to validate this for RHEL, anyway?

RH is doing some manual tests on their own, but also works with Intel's
Validation. Usually our Validation team works with end-user point of view,
but here we had to engage them to work with cli.py and confirm that
control over dpll works as expected.

HW agnostic tests were submitted by Michal as RFC for test framework
with fake modules implemented here:
https://lore.kernel.org/netdev/20230817152209.23868-1-michal.michalik@intel.com/#t
We had an agreement on latest dpll-meeting that we will follow up with
patches that would test dpll over fake modules, and we have started it.
As there was no requests to add HW-aware tests yet, we are not ready for
such submission yet. We could probably extended Michal's framework to
make it possible test real HW, but Michal's patches were just submitted,
we do expect some review/changes there, thus we could think of adding
something simpler for now..

Is simple bash script wrapping around cli.py and talking to ice dpll
while verifying the outputs, an acceptable solution?

Thank you!
Arkadiusz