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:   Tue, 15 Sep 2020 11:44:07 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Shannon Nelson <snelson@...sando.io>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v3 net-next 2/2] ionic: add devlink firmware update



On 9/15/2020 10:39 AM, Jakub Kicinski wrote:
> On Tue, 15 Sep 2020 10:20:11 -0700 Shannon Nelson wrote:
>>>>> What should the userland program do when the timeout expires?  Start
>>>>> counting backwards?  Stop waiting?  Do we care to define this at the moment?  
>>>> [component] bla bla X% (timeout reached)
>>>  
>>> Yep. I don't think userspace should bail or do anything but display
>>> here. Basically: the driver will timeout and then end the update
>>> process with an error. The timeout value is just a useful display
>>> so that users aren't confused why there is no output going on while
>>> waiting.
>>>
>> If individual notify messages have a timeout, how can we have a 
>> progress-percentage reported with a timeout?  This implies to me that 
>> the timeout is on the component:bla-bla pair, but there are many
>> notify messages in order to show the progress in percentage done.
>> This is why I was suggesting that if the timeout and component and
>> status messages haven't changed, then we're still working on the same
>> timeout.
> 
> My thinking is that the timeout is mostly useful for commands which
> can't meaningfully provide the progress percentage, or the percentage
> update is at a very high granularity. If percentage updates are reported
> often they should usually be sufficient.
> 
> We mostly want to make sure user doesn't think the system has hung.
> 

Exactly how I saw it.

Basically, the timeout should take effect as long as the (component,
msg) pair stays the same.

So if you send percentage reports with the same message and component,
then the timeout stays in effect. Once you start a new message, then the
timeout would be reset.

We could in theory provide both a "timeout" and "time elapsed" field,
which would allow the application to draw the timeout at an abitrary
point. Then it could progress the time as normal if it hasn't received a
new message yet, allowing for consistent screen updates...

But I think that might be overkill. For the cases where we do get some
sort of progress, then the percentage update is usually enough.

Powered by blists - more mailing lists