netdev - Re: [net-next 0/4] devlink: add dry run support for flash update

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YWA7keYHnhlHCkKT@nanopsycho>
Date:   Fri, 8 Oct 2021 14:37:37 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     netdev@...r.kernel.org, Jakub Kicinski <kubakici@...pl>
Subject: Re: [net-next 0/4] devlink: add dry run support for flash update

Fri, Oct 08, 2021 at 12:41:11PM CEST, jacob.e.keller@...el.com wrote:
>This is an implementation of a previous idea I had discussed on the list at
>https://lore.kernel.org/netdev/51a6e7a33c7d40889c80bf37159f210e@intel.com/
>
>The idea is to allow user space to query whether a given destructive devlink
>command would work without actually performing any actions. This is commonly
>referred to as a "dry run", and is intended to give tools and system
>administrators the ability to test things like flash image validity, or
>whether a given option is valid without having to risk performing the update
>when not sufficiently ready.
>
>The intention is that all "destructive" commands can be updated to support
>the new DEVLINK_ATTR_DRY_RUN, although this series only implements it for
>flash update.
>
>I expect we would want to support this for commands such as reload as well
>as other commands which perform some action with no interface to check state
>before hand.
>
>I tried to implement the DRY_RUN checks along with useful extended ACK
>messages so that even if a driver does not support DRY_RUN, some useful
>information can be retrieved. (i.e. the stack indicates that flash update is
>supported and will validate the other attributes first before rejecting the
>command due to inability to fully validate the run within the driver).

Hmm, old kernel vs. new-userspace, the requested dry-run, won't be
really dry run. I guess that user might be surprised in that case...


>
>Jacob Keller (4):
>  ice: move and rename ice_check_for_pending_update
>  ice: move ice_devlink_flash_update and merge with ice_flash_pldm_image
>  devlink: add dry run attribute to flash update
>  ice: support dry run of a flash update to validate firmware file
>
> Documentation/driver-api/pldmfw/index.rst     |  10 ++
> drivers/net/ethernet/intel/ice/ice_devlink.c  |  53 +-----
> .../net/ethernet/intel/ice/ice_fw_update.c    | 170 ++++++++++--------
> .../net/ethernet/intel/ice/ice_fw_update.h    |   7 +-
> include/linux/pldmfw.h                        |   5 +
> include/net/devlink.h                         |   2 +
> include/uapi/linux/devlink.h                  |   2 +
> lib/pldmfw/pldmfw.c                           |  12 ++
> net/core/devlink.c                            |  19 +-
> 9 files changed, 145 insertions(+), 135 deletions(-)
>
>
>base-commit: c514fbb6231483b05c97eb22587188d4c453b28e
>-- 
>2.31.1.331.gb0c09ab8796f
>