netdev - Re: [PATCH v2 0/3] devlink region trigger support

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]

Date:   Mon, 13 Jan 2020 19:33:04 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kubakici@...pl>,
        Yunsheng Lin <linyunsheng@...wei.com>,
        Alex Vesker <valex@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] devlink region trigger support

Mon, Jan 13, 2020 at 07:16:51PM CET, jacob.e.keller@...el.com wrote:
>On 1/13/2020 3:34 AM, Jakub Kicinski wrote:
>> On Mon, 13 Jan 2020 09:39:50 +0800, Yunsheng Lin wrote:
>>> I am not sure I understand "live region" here, what is the usecase of live
>>> region?
>> 
>> Reading registers of a live system without copying them to a snapshot
>> first. Some chips have so many registers it's impractical to group them
>> beyond "registers of IP block X", if that. IMHO that fits nicely with
>> regions, health is grouped by event, so we'd likely want to dump for
>> example one or two registers from the MAC there, while the entire set
>> of MAC registers can be exposed as a region.
>> 
>
>Right. I'm actually wondering about this as well. Region snapshots are
>captured in whole and stored and then returned through the devlink
>region commands.

Well, driver does not have to support snapshots for particular region,
only live reading. Yes, this needs to be implemented.

>
>This could be problematic if you wanted to expose a larger chunk of
>registers or addressable sections of flash contents, as the size of the
>contents goes beyond a single page.
>
>If we instead focus regions onto the live-read aspect, the API can
>simply be a request to read a segment of the region. Then, the driver
>could perform the read of that chunk and report it back.

Yep.