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: <CALzJLG_a4s54MwCzOHMeCp0i5F5pyb-PHY_AFA-ok2JT5S62wQ@mail.gmail.com>
Date:	Fri, 29 Apr 2016 23:27:06 +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 Wed, Apr 27, 2016 at 12:41 AM, David Miller <davem@...emloft.net> wrote:
> From: Saeed Mahameed <saeedm@....mellanox.co.il>
> Date: Tue, 26 Apr 2016 23:55:03 +0300
>
>> It will be a nightmare to rollback in such case.  What if the rollback failed ?
>
> It is absolutely essential to handle this properly.
>
> Which means you must have a prepare/commit model, wherein the prepare
> phase makes sure to pre-allocate all necessary resources, and only if
> all the prepare phase preparations succeed will the commit phase run.
>
> The commit phase cannot error, because all of the resources have been
> allocated successfully already.
>
> This way there are no issues of "rolling back" because you never
> actually move the state forward until you can guarantee that you can
> do everything.

Right, for pure software/kernel resources this is the right way to go,
Actually we already have a patch that is similar of what you described,
we are aiming to push it towards 4.8.

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).