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

Message-Id: <20160429.163446.928550855039136205.davem@davemloft.net>
Date:	Fri, 29 Apr 2016 16:34:46 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	saeedm@....mellanox.co.il
Cc:	saeedm@...lanox.com, netdev@...r.kernel.org, ogerlitz@...lanox.com,
	talal@...lanox.com, eranbe@...lanox.com
Subject: Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool
 support

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.