netdev - Re: [RFCv2 net-next 000/167] net: extend the netdev_features

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:   Thu, 30 Sep 2021 11:15:05 +0800
From:   "shenjian (K)" <shenjian15@...wei.com>
To:     Edward Cree <ecree.xilinx@...il.com>, <davem@...emloft.net>,
        <kuba@...nel.org>, <andrew@...n.ch>, <hkallweit1@...il.com>
CC:     <netdev@...r.kernel.org>, <linuxarm@...neuler.org>
Subject: Re: [RFCv2 net-next 000/167] net: extend the netdev_features_t

Hi, edward


在 2021/9/30 8:55, Edward Cree 写道:
> On 29/09/2021 16:50, Jian Shen wrote:
>> This patchset try to solve it by change the prototype of
>> netdev_features_t from u64 to bitmap. With this change,
>> it's necessary to introduce a set of bitmap operation helpers
>> for netdev features. Meanwhile, the functions which use
>> netdev_features_t as return value are also need to be changed,
>> return the result as an output parameter.
> This might be a terrible idea, but could you not do something like
>      typedef struct {
>          DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT);
>      } netdev_features_t;
>   thereby allowing functions to carry on returning it directly?
> The compiler would still likely turn it into an output parameter
>   at an ABI level (at least once NETDEV_FEATURE_COUNT goes above
>   64), but the amount of code churn might be significantly reduced.
> Another advantage is that, whereas bitwise ops (&, |, ^) on a
>   pointer (such as unsigned long *) are legal (meaning something
>   like "if (features & NETIF_F_GSO_MASK)" may still compile, at
>   best with a warning, despite having nonsensical semantics), they
>   aren't possible on a struct; so there's less risk of unpatched
>   code (perhaps merged in from another subsystem, or in out-of-tree
>   modules) silently breaking — instead, any mix of new and old code
>   will be caught at build time.
>
> WDYT?
> -ed
> .
Thanks for your advice.  It looks good to me.

The risk of misusing bitwise ops, and not be reported by  compiler is 
truely
exist in my patchset.  I will consider the way of using structure.

shenjian