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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 3 Sep 2020 14:35:34 -0700
From:   Shannon Nelson <>
To:     Jiri Pirko <>
Subject: Re: [PATCH net-next 2/2] ionic: add devlink firmware update

On 9/3/20 10:30 AM, Jiri Pirko wrote:
> Thu, Sep 03, 2020 at 05:58:42PM CEST, wrote:
>> True, they aren't "needed" for operational purposes, but they are rather
>> useful when inspecting a system after getting a report of bad behavior, and
> I don't think it is nice to pollute dmesg with any arbitrary driver-specific
> messages.
>> since this should be seldom performed there should be no risk of filling the
>> log.  As far as I can tell, the devlink messages are only seen at the time
>> the flash is performed as output from the flash command, or from a devlink
>> monitor if someone started it before the flash operation.  Is there any other
>> place that can be inspected later that will indicate someone was fussing with
>> the firmware?
> Not really, no. But perhaps we can have a counter for that. Similar to
> what Jakub suggested for reload.

When we need to debug a complaint about a firmware load, I want to be 
able to find out what fw file the user actually tried to load, and maybe 
were there other broken load attempts before that.  If there was 
something that broke in the download, it would be nice to know when - 
beginning?  4k bytes in?  near the end?  A counter might show a number 
of load attempts, but no context as to when, what file, or what else was 
going on around the same time.


Powered by blists - more mailing lists