netdev - Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

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:	Sat, 30 Apr 2016 00:14:00 +0300
From:	Saeed Mahameed <saeedm@....mellanox.co.il>
To:	David Miller <davem@...emloft.net>
Cc:	Saeed Mahameed <saeedm@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Tal Alon <talal@...lanox.com>,
	Eran Ben Elisha <eranbe@...lanox.com>
Subject: Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

On Fri, Apr 29, 2016 at 11:34 PM, David Miller <davem@...emloft.net> wrote:
> From: Saeed Mahameed <saeedm@....mellanox.co.il>
> Date: Fri, 29 Apr 2016 23:27:06 +0300
>
>> but my concerns is when features A and B requires firmware commands A then B
>> and firmware command B fails, there is no gurantee that roll back for
>> firmware command A will work.
>>
>> this is why in case of B fails we keep the state (new A and prev B)
>> rather than try to go back to (prev A and prev B).
>
> That's a limitation of your firmware I would say.
>
> Users do not expect the semantics you will be providing, if "change A and B"
> fails both states must not be changed.
>
> This is an unwavering requirement, you must do everything you can to
> meet that expection.
>
> You cannot say "our firmware does this so, you might get partial
> updates."  That simply is not acceptable.

Got it, we'll revisit this area of code and make meet the requirement.

Thank you Dave.