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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 19 Aug 2020 17:23:25 +0300
From:   Moshe Shemesh <moshe@...dia.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     Jakub Kicinski <kuba@...nel.org>,
        Moshe Shemesh <moshe@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next RFC v2 01/13] devlink: Add reload action option
 to devlink reload command


On 8/19/2020 3:46 PM, Jiri Pirko wrote:
> Wed, Aug 19, 2020 at 02:18:22PM CEST, moshe@...dia.com wrote:
>> On 8/19/2020 3:10 AM, Jakub Kicinski wrote:
>>> On Tue, 18 Aug 2020 12:10:36 +0300 Moshe Shemesh wrote:
>>>> On 8/17/2020 7:36 PM, Jiri Pirko wrote:
>>>>> Mon, Aug 17, 2020 at 11:37:40AM CEST, moshe@...lanox.com wrote:
>>>>>> Add devlink reload action to allow the user to request a specific reload
>>>>>> action. The action parameter is optional, if not specified then devlink
>>>>>> driver re-init action is used (backward compatible).
>>>>>> Note that when required to do firmware activation some drivers may need
>>>>>> to reload the driver. On the other hand some drivers may need to reset
>>>>> Sounds reasonable. I think it would be good to indicate that though. Not
>>>>> sure how...
>>>> Maybe counters on the actions done ? Actually such counters can be
>>>> useful on debug, knowing what reloads we had since driver was up.
>>> Wouldn't we need to know all types of reset of drivers may do?
>>
>> Right, we can't tell all reset types driver may have, but we can tell which
>> reload actions were done.
>>
>>> I think documenting this clearly should be sufficient.
>>>
>>> A reset counter for the _requested_ reset type (fully maintained by
>>> core), however - that may be useful. The question "why did this NIC
>>> reset itself / why did the link just flap" comes up repeatedly.
>>
>> I will add counters on which reload were done. reload_down()/up() can return
>> which actions were actually done and devlink will show counters.
> Why a counter? Just return what was done over netlink reply.


Such counters can be useful for debugging, telling which reload actions 
were done on this dev from the point it was up.

Powered by blists - more mailing lists