netdev - Re: [PATCH net-next v2 0/3] net: device features handling fixes

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] [day] [month] [year] [list]

Message-Id: <20140522.150757.314142708479740813.davem@davemloft.net>
Date:	Thu, 22 May 2014 15:07:57 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	mkubecek@...e.cz
Cc:	netdev@...r.kernel.org, kaber@...sh.net, j.vosburgh@...il.com,
	vfalico@...il.com, andy@...yhouse.net, jiri@...nulli.us,
	mirq-linux@...e.qmqm.pl
Subject: Re: [PATCH net-next v2 0/3] net: device features handling fixes

From: Michal Kubecek <mkubecek@...e.cz>
Date: Tue, 20 May 2014 08:29:15 +0200 (CEST)

>> I think we need to think more about what exact behavior is desired in
>> mixed csum feature set cases.  Probably whatever csum offload type is
>> the most prevelant should be the one advertised by the master.  It
>> means we will do that software checksum fixup for the oddball slaves,
>> but it seems the best we can do.
> 
> I've been thinking about it some more and I believe what I proposed is
> correct: features that are or-ed (ONE_FOR_ALL) should start with 0,
> those which are and-ed (ALL_FOR_ALL) with 1.
> 
> But once we do that, we have to fix another problem in vlan module:
> features of a vlan device are mostly computed as bitwise AND of features
> and vlan_features of its underlying device. The problem is checksumming
> features don't really behave like independent flags as their main
> purpose is to be used in can_checksum_protocol() whose logic is that
> HW_CSUM (GEN_CSUM) means "can checksum everything" so that it kind of
> contains IP(V6)_CSUM functionality. Therefore intersection of HW_CSUM
> and IP(V6)_CSUM should result in the latter.
> 
> An alternative approach would be to always set IP(V6)_CSUM once HW_CSUM
> (any of GEN_CSUM) is set but as for long time people were taught not to
> do that and we even have a warning for it, switching to the exact
> opposite could cause a lot of problems.

Ok, looks good, series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html