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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Aug 2020 07:46:26 +0200 From: Jiri Pirko <jiri@...nulli.us> To: Jakub Kicinski <kuba@...nel.org> Cc: Moshe Shemesh <moshe@...lanox.com>, Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Jiri Pirko <jiri@...lanox.com>, Vasundhara Volam <vasundhara-v.volam@...adcom.com> Subject: Re: [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command Mon, Aug 10, 2020 at 06:53:05PM CEST, kuba@...nel.org wrote: >On Sun, 9 Aug 2020 16:21:29 +0300 Moshe Shemesh wrote: >> Okay, so devlink reload default for mlx5 will include also fw-activate >> to align with mlxsw default. >> >> Meaning drivers that supports fw-activate will add it to the default. > >No per-driver default. > >Maybe the difference between mlxsw and mlx5 can be simply explained by >the fact that mlxsw loads firmware from /lib/firmware on every probe >(more or less). > >It's only natural for a driver which loads FW from disk to load it on >driver reload. We don't load it on reaload... We just do reset witn activation. > >> The flow of devlink reload default on mlx5 will be: >> >> If there is FW image pending and live patch is suitable to apply, do >> live patch and driver re-initialization. >> >> If there is FW image pending but live patch doesn't fit do fw-reset and >> driver-initialization. >> >> If no FW image pending just do driver-initialization. > >This sounds too complicated. Don't try to guess what the user wants. > >> I still think I should on top of that add the level option to be >> selected by the user if he prefers a specific action, so the uAPI would be: >> >> devlink dev reload [ netns { PID | NAME | ID } ] [ level { fw-live-patch >> | driver-reinit |fw-activate } ] > >I'm all for the level/action. > >> But I am still missing something: fw-activate implies that it will >> activate a new FW image stored on flash, pending activation. What if the >> user wants to reset and reload the FW if no new FW pending ? Should we >> add --force option to fw-activate level ? > >Since reload does not check today if anything changed - i.e. if reload >is actually needed, neither should fw-activate, IMO. I'd expect the >"--force behavior" to be the default.
Powered by blists - more mailing lists