| 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
| ||
|
Message-ID: <CAHLZf_uw-WtT3ztY=U5M1isxvpvUhPpPXYi2jk2UJxtsWMtBkQ@mail.gmail.com>
Date: Wed, 13 Jul 2022 15:46:03 +0530
From: Vikas Gupta <vikas.gupta@...adcom.com>
To: Jiri Pirko <jiri@...dia.com>
Cc: Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>, dsahern@...nel.org,
stephen@...workplumber.org, Eric Dumazet <edumazet@...gle.com>,
pabeni@...hat.com, ast@...nel.org, leon@...nel.org,
linux-doc@...r.kernel.org, corbet@....net,
Michael Chan <michael.chan@...adcom.com>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 1/3] devlink: introduce framework for selftests
Hi Jiri,
On Wed, Jul 13, 2022 at 12:58 PM Jiri Pirko <jiri@...dia.com> wrote:
>
> Wed, Jul 13, 2022 at 08:40:50AM CEST, vikas.gupta@...adcom.com wrote:
> >Hi Jiri,
> >
> >On Tue, Jul 12, 2022 at 11:38 PM Jiri Pirko <jiri@...nulli.us> wrote:
> >>
> >> Tue, Jul 12, 2022 at 06:41:49PM CEST, vikas.gupta@...adcom.com wrote:
> >> >Hi Jiri,
> >> >
> >> >On Tue, Jul 12, 2022 at 11:58 AM Jiri Pirko <jiri@...dia.com> wrote:
> >> >>
> >> >> Tue, Jul 12, 2022 at 08:16:11AM CEST, vikas.gupta@...adcom.com wrote:
> >> >> >Hi Jiri,
> >> >> >
> >> >> >On Mon, Jul 11, 2022 at 6:10 PM Jiri Pirko <jiri@...dia.com> wrote:
> >> >> >
> >> >> >> Thu, Jul 07, 2022 at 08:29:48PM CEST, vikas.gupta@...adcom.com wrote:
> >>
> >> [...]
> >>
> >>
> >> >> >> > * enum devlink_trap_action - Packet trap action.
> >> >> >> > * @DEVLINK_TRAP_ACTION_DROP: Packet is dropped by the device and a copy
> >> >> >> is not
> >> >> >> >@@ -576,6 +598,10 @@ enum devlink_attr {
> >> >> >> > DEVLINK_ATTR_LINECARD_TYPE, /* string */
> >> >> >> > DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES, /* nested */
> >> >> >> >
> >> >> >> >+ DEVLINK_ATTR_SELFTESTS_MASK, /* u32 */
> >> >> >>
> >> >> >> I don't see why this is u32 bitset. Just have one attr per test
> >> >> >> (NLA_FLAG) in a nested attr instead.
> >> >> >>
> >> >> >
> >> >> >As per your suggestion, for an example it should be like as below
> >> >> >
> >> >> > DEVLINK_ATTR_SELFTESTS, /* nested */
> >> >> >
> >> >> > DEVLINK_ATTR_SELFTESTS_SOMETEST1 /* flag */
> >> >> >
> >> >> > DEVLINK_ATTR_SELFTESTS_SOMETEST2 /* flag */
> >> >>
> >> >> Yeah, but have the flags in separate enum, no need to pullute the
> >> >> devlink_attr enum by them.
> >> >>
> >> >>
> >> >> >
> >> >> >.... <SOME MORE TESTS>
> >> >> >
> >> >> >.....
> >> >> >
> >> >> > DEVLINK_ATTR_SLEFTESTS_RESULT_VAL, /* u8 */
> >> >> >
> >> >> >
> >> >> >
> >> >> > If we have this way then we need to have a mapping (probably a function)
> >> >> >for drivers to tell them what tests need to be executed based on the flags
> >> >> >that are set.
> >> >> > Does this look OK?
> >> >> > The rationale behind choosing a mask is that we could directly pass the
> >> >> >mask-value to the drivers.
> >> >>
> >> >> If you have separate enum, you can use the attrs as bits internally in
> >> >> kernel. Add a helper that would help the driver to work with it.
> >> >> Pass a struct containing u32 (or u8) not to drivers. Once there are more
> >> >> tests than that, this structure can be easily extended and the helpers
> >> >> changed. This would make this scalable. No need for UAPI change or even
> >> >> internel driver api change.
> >> >
> >> >As per your suggestion, selftest attributes can be declared in separate
> >> >enum as below
> >> >
> >> >enum {
> >> >
> >> > DEVLINK_SELFTEST_SOMETEST, /* flag */
> >> >
> >> > DEVLINK_SELFTEST_SOMETEST1,
> >> >
> >> > DEVLINK_SELFTEST_SOMETEST2,
> >> >
> >> >....
> >> >
> >> >......
> >> >
> >> > __DEVLINK_SELFTEST_MAX,
> >> >
> >> > DEVLINK_SELFTEST_MAX = __DEVLINK_SELFTEST_MAX - 1
> >> >
> >> >};
> >> >Below examples could be the flow of parameters/data from user to
> >> >kernel and vice-versa
> >> >
> >> >
> >> >Kernel to user for show command . Users can know what all tests are
> >> >supported by the driver. A return from kernel to user.
> >> >______
> >> >|NEST |
> >> >|_____ |TEST1|TEST4|TEST7|...
> >> >
> >> >
> >> >User to kernel to execute test: If user wants to execute test4, test8, test1...
> >> >______
> >> >|NEST |
> >> >|_____ |TEST4|TEST8|TEST1|...
> >> >
> >> >
> >> >Result Kernel to user execute test RES(u8)
> >> >______
> >> >|NEST |
> >> >|_____ |RES4|RES8|RES1|...
> >>
> >> Hmm, I think it is not good idea to rely on the order, a netlink library
> >> can perhaps reorder it? Not sure here.
> >>
> >> >
> >> >Results are populated in the same order as the user passed the TESTs
> >> >flags. Does the above result format from kernel to user look OK ?
> >> >Else we need to have below way to form a result format, a nest should
> >> >be made for <test_flag,
> >> >result> but since test flags are in different enum other than
> >> >devlink_attr and RES being part of devlink_attr, I believe it's not
> >> >good practice to make the below structure.
> >>
> >> Not a structure, no. Have it as another nest (could be the same attr as
> >> the parent nest:
> >>
> >> ______
> >> |NEST |
> >> |_____ |NEST| |NEST| |NEST|
> >> TEST4,RES4 TEST8,RES8 TEST1, RES1
> >>
> >> also, it is flexible to add another attr if needed (like maybe result
> >> message string containing error message? IDK).
> >
> >For above nesting we can have the attributes defined as below
> >
> >Attribute in devlink_attr
> >enum devlink_attr {
> > ....
> > ....
> > DEVLINK_SELFTESTS_INFO, /* nested */
> > ...
> >...
> >}
> >
> >enum devlink_selftests {
> > DEVLINK_SELFTESTS_SOMETEST0, /* flag */
> > DEVLINK_SELFTESTS_SOMETEST1,
> > DEVLINK_SELFTESTS_SOMETEST2,
> > ...
> > ...
> >}
> >
> >enum devlink_selftest_result {
>
> for attrs, have "attr" in the name of the enum and "ATTR" in name of the
> value.
>
> > DEVLINK_SELFTESTS_RESULT, /* nested */
> > DEVLINK_SELFTESTS_TESTNUM, /* u32 indicating the test
>
> You can have 1 enum, containing both these and the test flags from
> above.
I think it's better to keep enum devlink_selftests_attr (containing
flags) and devlink_selftest_result_attr separately as it will have an
advantage.
For example, for show commands the kernel can iterate through and
check with the driver if it supports a particular test.
for (i = 0; i < DEVLINK_SELFTEST_ATTR_MAX, i++) {
if (devlink->ops->selftest_info(devlink, i,
extack)) { // supports selftest or not
nla_put_flag(msg, i);
}
}
Also flags in devlink_selftests_attr can be used as bitwise, if required.
Let me know what you think.
Thanks,
Vikas
>
>
> >number in devlink_selftests enum */
> > DEVLINK_SELFTESTS_RESULT_VAL, /* u8 skip, pass, fail.. */
>
> Put enum name in the comment, instead of list possible values.
>
>
> > ...some future attrr...
> >
> >}
> >enums in devlink_selftest_result can be put in devlink_attr though.
>
> You can have them separate, I think it is about the time we try to put
> new attrs what does not have potencial to be re-used to a separate enum.
>
>
> >
> >Does this look OK?
> >
> >Thanks,
> >Vikas
> >
> >>
> >>
> >>
> >> >______
> >> >|NEST |
> >> >|_____ | TEST4, RES4|TEST8,RES8|TEST1,RES1|...
> >> >
> >> >Let me know if my understanding is correct.
> >>
> >> [...]
>
>
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4206 bytes)
Powered by blists - more mailing lists