netdev - Re: [PATCH net-next 2/4] net/mlx4: Preparation for VST QinQ

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]

Date:	Mon, 11 Jul 2016 13:33:04 +0300
From:	Tariq Toukan <ttoukan.linux@...il.com>
To:	Tariq Toukan <tariqt@...lanox.com>,
	Or Gerlitz <gerlitz.or@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Eran Ben Elisha <eranbe@...lanox.com>,
	Moshe Shemesh <moshe@...lanox.com>
Subject: Re: [PATCH net-next 2/4] net/mlx4: Preparation for VST QinQ

On 10/07/2016 7:00 PM, Tariq Toukan wrote:
>>> Add func capability vlan_offload_disable to disable all vlan HW
>>> acceleration on VF while the VF is set to VST QinQ mode.
>> this part (above two lines) is code running in the VF Eth driver, correct? if this is indeed the case, break the patch to two (1) PF core driver  (2) VF core/EN driver
>>
>> What happens if the VF doesn't work as you expect? e.g the PF runs your code and the VF driver is unpatched?
> Good point, currently if the administrator sets the configuration then it just silently not fail. We will use a mechanism that prevents this.
* silently fails