netdev - Re: [RFC PATCH net-next 1/7] net: ethtool: netlink: introduce ethnl_update

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:   Wed, 17 Aug 2022 11:52:57 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Michal Kubecek <mkubecek@...e.cz>
CC:     "netdev@...r.kernel.org" <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>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Rui Sousa <rui.sousa@....com>,
        Ferenc Fejes <ferenc.fejes@...csson.com>
Subject: Re: [RFC PATCH net-next 1/7] net: ethtool: netlink: introduce
 ethnl_update_bool()

On Wed, Aug 17, 2022 at 01:27:29PM +0200, Michal Kubecek wrote:
> On Wed, Aug 17, 2022 at 01:29:14AM +0300, Vladimir Oltean wrote:
> > For a reason I can't really understand, ethnl_update_bool32() exists,
> > but the plain function that operates on a boolean value kept in an
> > actual u8 netlink attribute doesn't.
> 
> I can explain that: at the moment these helpers were introduced, only
> members of traditional structures shared with ioctl interface were
> updated and all attributes which were booleans logically were
> represented as u32 in them so that no other helper was needed back then.

Thanks, but the internal data structures of the kernel did not
necessitate boolean netlink attributes to be promoted to u32 just
because the ioctl interface did it that way; or did they?

Or otherwise said, is there a technical requirement that if a boolean is
passed to the kernel as u32 via ioctl, it should be passed as u32 via
netlink too?