netdev - Re: [RFC iproute2-next] devlink: display elapsed time during flash update

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] [day] [month] [year] [list]

Message-ID: <a645c270-0219-1908-0f8d-ed2569d4bf57@intel.com>
Date:   Tue, 29 Sep 2020 12:04:36 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Jakub Kicinski <kubakici@...pl>, netdev@...r.kernel.org,
        snelson@...sando.io
Subject: Re: [RFC iproute2-next] devlink: display elapsed time during flash
 update



On 9/29/2020 11:45 AM, Jacob Keller wrote:
> 
> 
> On 9/29/2020 11:07 AM, Ido Schimmel wrote:
>> On Tue, Sep 29, 2020 at 10:56:23AM -0700, Jacob Keller wrote:
>>>
>>>
>>> On 9/29/2020 10:18 AM, Jakub Kicinski wrote:
>>>> On Mon, 28 Sep 2020 16:49:45 -0700 Jacob Keller wrote:
>>>>> For some devices, updating the flash can take significant time during
>>>>> operations where no status can meaningfully be reported. This can be
>>>>> somewhat confusing to a user who sees devlink appear to hang on the
>>>>> terminal waiting for the device to update.
>>>>>
>>>>> Provide a ticking counter of the time elapsed since the previous status
>>>>> message in order to make it clear that the program is not simply stuck.
>>>>>
>>>>> Do not display this message unless a few seconds have passed since the
>>>>> last status update. Additionally, if the previous status notification
>>>>> included a timeout, display this as part of the message. If we do not
>>>>> receive an error or a new status without that time out, replace it with
>>>>> the text "timeout reached".
>>>>>
>>>>> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
>>>>> ---
>>>>> Sending this as an RFC because I doubt this is the best implementation. For
>>>>> one, I get a weird display issue where the cursor doesn't always end up on
>>>>> the end of line in my shell.. The % display works properly, so I'm not sure
>>>>> what's wrong here.
>>>>>
>>>>> Second, even though select should be timing out every 1/10th of a second for
>>>>> screen updates, I don't seem to get that behavior in my test. It takes about
>>>>> 8 to 10 seconds for the first elapsed time message to be displayed, and it
>>>>> updates really slowly. Is select just not that precise? I even tried using a
>>>>> timeout of zero, but this means we refresh way too often and it looks bad. I
>>>>> am not sure what is wrong here...
>>>>
>>>> Strange. Did you strace it? Perhaps it's some form of output buffering?
>>>>
>>>
>>> Haven't yet, just noticed the weird output behavior and timing
>>> inconsistency.
>>
>> Might be similar to this:
>> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=8e6bce735a132150c23503a55ea0aef55a01425f
>>
> 
> Yep, I needed the fflush! That resolved the display issue!
> 
> Thanks,
> Jake
> 

This also appears to have resolved the weird timing aspect.. the line
wasn't flushed right away. strace with relative timestamps confirmed
that select was infact waking up.

I'll post a non-RFC version that includes the suggested cleanups from
Jakub. Shannon, I'd appreciate if you could try out the next revision
with your device to see if it looks good!

Thanks,
Jake