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: <20201118163427.GB3055@nanopsycho.orion>
Date:   Wed, 18 Nov 2020 17:34:27 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     netdev@...r.kernel.org, Jiri Pirko <jiri@...dia.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Shannon Nelson <snelson@...sando.io>,
        Saeed Mahameed <saeedm@...dia.com>,
        Boris Pismenny <borisp@...dia.com>,
        Bin Luo <luobin9@...wei.com>, Jakub Kicinksi <kuba@...nel.org>
Subject: Re: [net-next v3 2/2] devlink: move flash end and begin to core
 devlink

Tue, Nov 17, 2020 at 09:08:20PM CET, jacob.e.keller@...el.com wrote:
>When performing a flash update via devlink, device drivers may inform
>user space of status updates via
>devlink_flash_update_(begin|end|timeout|status)_notify functions.
>
>It is expected that drivers do not send any status notifications unless
>they send a begin and end message. If a driver sends a status
>notification without sending the appropriate end notification upon
>finishing (regardless of success or failure), the current implementation
>of the devlink userspace program can get stuck endlessly waiting for the
>end notification that will never come.
>
>The current ice driver implementation may send such a status message
>without the appropriate end notification in rare cases.
>
>Fixing the ice driver is relatively simple: we just need to send the
>begin_notify at the start of the function and always send an end_notify
>no matter how the function exits.
>
>Rather than assuming driver authors will always get this right in the
>future, lets just fix the API so that it is not possible to get wrong.
>Make devlink_flash_update_begin_notify and
>devlink_flash_update_end_notify static, and call them in devlink.c core
>code. Always send the begin_notify just before calling the driver's
>flash_update routine. Always send the end_notify just after the routine
>returns regardless of success or failure.
>
>Doing this makes the status notification easier to use from the driver,
>as it no longer needs to worry about catching failures and cleaning up
>by calling devlink_flash_update_end_notify. It is now no longer possible
>to do the wrong thing in this regard. We also save a couple of lines of
>code in each driver.
>
>Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>

Good idea.

Reviewed-by: Jiri Pirko <jiri@...dia.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ