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-next>] [day] [month] [year] [list]
Message-ID: <f8e67e40-71d4-f03c-6bc0-6496663af895@broadcom.com>
Date:   Mon, 3 Feb 2020 15:01:37 -0800
From:   Ray Jui <ray.jui@...adcom.com>
To:     Jiri Pirko <jiri@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ray Jui <ray.jui@...adcom.com>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>
Subject: RFC: Use of devlink/health report for non-Ethernet devices

Hi Jiri/Eran/David,

I've been investigating the health report feature of devlink, and have a 
couple related questions as follows:

1. Based on my investigation, it seems that devlink health report 
mechanism provides the hook for a device driver to report errors, dump 
debug information, trigger object dump, initiate self-recovery, and etc. 
The current users of health report are all Ethernet based drivers. 
However, it does not seem the health report framework prohibits the use 
from any non-Ethernet based device drivers. Is my understanding correct?

2. Following my first question, in this case, do you think it makes any 
sense to use devlink health report as a generic error reporting and 
recovery mechanism, for other devices, e.g., NVMe and Virt I/O?

3. In the Ethernet device driver based use case, if one has a "smart 
NIC" type of platform, i.e., running Linux on the embedded processor of 
the NIC, it seems to make a lot of sense to also use devlink health 
report to deal with other non-Ethernet specific errors, originated from 
the embedded Linux (or any other OSes). The front-end driver that 
registers various health reporters will still be an Ethernet based 
device driver, running on the host server system. Does this make sense 
to you?

Thanks in advance for your feedback!

Thanks,

Ray


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ