linux-kernel - Re: [PATCH net-next v8 03/14] ethtool: netlink bitset handling

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: <b36ee759-2d7a-8237-6f3d-a93e8c22ba66@gmail.com>
Date:   Mon, 23 Dec 2019 20:15:22 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Michal Kubecek <mkubecek@...e.cz>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>,
        John Linville <linville@...driver.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Johannes Berg <johannes@...solutions.net>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v8 03/14] ethtool: netlink bitset handling



On 12/22/2019 3:45 PM, Michal Kubecek wrote:
> The ethtool netlink code uses common framework for passing arbitrary
> length bit sets to allow future extensions. A bitset can be a list (only
> one bitmap) or can consist of value and mask pair (used e.g. when client
> want to modify only some bits). A bitset can use one of two formats:
> verbose (bit by bit) or compact.
> 
> Verbose format consists of bitset size (number of bits), list flag and
> an array of bit nests, telling which bits are part of the list or which
> bits are in the mask and which of them are to be set. In requests, bits
> can be identified by index (position) or by name. In replies, kernel
> provides both index and name. Verbose format is suitable for "one shot"
> applications like standard ethtool command as it avoids the need to
> either keep bit names (e.g. link modes) in sync with kernel or having to
> add an extra roundtrip for string set request (e.g. for private flags).
> 
> Compact format uses one (list) or two (value/mask) arrays of 32-bit
> words to store the bitmap(s). It is more suitable for long running
> applications (ethtool in monitor mode or network management daemons)
> which can retrieve the names once and then pass only compact bitmaps to
> save space.
> 
> Userspace requests can use either format; ETHTOOL_FLAG_COMPACT_BITSETS
> flag in request header tells kernel which format to use in reply.
> Notifications always use compact format.
> 
> As some code uses arrays of unsigned long for internal representation and
> some arrays of u32 (or even a single u32), two sets of parse/compose
> helpers are introduced. To avoid code duplication, helpers for unsigned
> long arrays are implemented as wrappers around helpers for u32 arrays.
> There are two reasons for this choice: (1) u32 arrays are more frequent in
> ethtool code and (2) unsigned long array can be always interpreted as an
> u32 array on little endian 64-bit and all 32-bit architectures while we
> would need special handling for odd number of u32 words in the opposite
> direction.
> 
> Signed-off-by: Michal Kubecek <mkubecek@...e.cz>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian