netdev - Re: [PATCH V2 net] netdevice: Include NETIF_F_HW

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, 21 Apr 2017 13:33:58 -0400
From:   Vladislav Yasevich <vyasevich@...il.com>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     Vlad Yasevich <vyasevic@...hat.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Netdev <netdev@...r.kernel.org>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH V2 net] netdevice: Include NETIF_F_HW_CSUM when
 intersecting features

On Fri, Apr 21, 2017 at 1:33 AM, Michal Kubecek <mkubecek@...e.cz> wrote:
> On Thu, Apr 20, 2017 at 07:19:55PM -0400, Vlad Yasevich wrote:
>>
>> Having said that, the other alternative is to inherit hw_features from
>> lower devices.  BTW, bonding I think has a similar "issue" you are
>> describing since it prefers HW_CSUM if any of the slaves have it set.
>
> It does but bonding uses netdev_increment_features() to combine slave
> features and this function handles checksumming like "or", not "and"
> (not only checksumming, also flags in NETIF_F_ONE_FOR_ALL).
>

I am not saying that it doesn't.  What I am saying is that if you
form a bond with two devices: one with only NETIF_F_IP_CSUM and the
other with NETIF_F_HW_CSUM, then the bonding device will have NETIF_F_HW_CSUM
set.  This is similar to what is being proposed in the patch.

Alex's objection, at least as I understand it, is that we never want to
allow the above condition.  However, it looks like we already allow it
and correctly handle it.

> That said, it's legitimate to ask if we want some of the features to be
> handled differently when computing features for a vlan device. My point
> before was that if the helper is called netdev_intersect_features(), it
> shouldn't return any features that are not supported by both argument
> sets, even if all its current users would benefit from slightly
> different behaviour. If it does, it's a trap that someone might one day
> fall in.

Ok.  I think I understand, but we've always handled the checksum intersection
stangely.  I'll see what I can figure out.

Thanks
-vlad

>
>                                                          Michal Kubecek
>