linux-kernel - Re: [RFC PATCH] net: devlink: devlink_nl_info

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]

Date:   Fri, 25 Nov 2022 01:20:14 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Jiri Pirko <jiri@...dia.com>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] net: devlink: devlink_nl_info_fill: populate default information

On Wed. 23 Nov. 2022 at 21:10, Jiri Pirko <jiri@...dia.com> wrote:
> Wed, Nov 23, 2022 at 12:00:44PM CET, mailhol.vincent@...adoo.fr wrote:
> >On Wed. 23 nov. 2022 à 18:46, Jiri Pirko <jiri@...dia.com> wrote:
> >> Tue, Nov 22, 2022 at 04:49:34PM CET, mailhol.vincent@...adoo.fr wrote:

(...)

> >> >+      if (!strcmp(dev->parent->type->name, "usb_device")) {
> >>
> >> Comparing to string does not seem correct here.
> >
> >There is a is_usb_device() which does the check:
> >  https://elixir.bootlin.com/linux/v6.1-rc1/source/drivers/usb/core/usb.h#L152
> >
> >but this macro is not exposed outside of the usb core. The string
> >comparison was the only solution I found.
>
> Find a different one. String check here is wrong.

After looking again, I found no alternative and so I asked the USB
mailing list and got an answer from Greg. There is no ways to do so
and the class code is not supposed to do this:
https://lore.kernel.org/linux-usb/Y3+VfNdt%2FK7UtRcw@kroah.com/

So I guess that there will be no code factorization for device specific values.

@Jakub, with this in mind, does it still make sense to add the bitmap?
Aside from the driver name, it seems that there will be no code
factorization for other types dependent values. If we only set the
driver name at the core level, I would rather just clean up the
existing. (Side comment, I finished implementing the bitmap just
before receiving Greg's answer; I guess my code will go to the trash
can...)