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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Sep 2020 08:50:45 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     "Keller, Jacob E" <jacob.e.keller@...el.com>,
        "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 Mon, 14 Sep 2020 18:14:22 -0700 Shannon Nelson wrote:
> So now we're beginning to dance around timeout boundaries - how can we 
> define the beginning and end of a timeout boundary, and how do they 
> relate to the component and label?  Currently, if either the component 
> or status_msg changes, the devlink user program does a newline to start 
> a new status line.  The done and total values are used from each notify 
> message to create a % value displayed, but are not dependent on any 
> previous done or total values, so the total doesn't need to be the same 
> value from status message to status message, even if the component and 
> label remain the same, devlink will just print whatever % gets 
> calculated that time.

I think systemd removes the timeout marking when it moves on to the
next job, and so should devlink when it moves on to the next
component/status_msg.

> I'm thinking that the behavior of the timeout value should remain 
> separate from the component and status_msg values, such that once given, 
> then the userland countdown continues on that timeout.  Each subsequent 
> notify, regardless of component or label changes, should continue 
> reporting that same timeout value for as long as it applies to the 
> action.  If a new timeout value is reported, the countdown starts over.  

What if no timeout exists for the next action? Driver reports 0 to
"clear"?

> This continues until either the countdown finishes or the driver reports 
> the flash as completed.  I think this allows is the flexibility for 
> multiple steps that Jake alludes to above.  Does this make sense?

I disagree. This doesn't match reality/driver behavior and will lead to
timeouts counting to some random value, that's to say the drivers
timeout instant will not match when user space reaches timeout.

The timeout should be per notification, because drivers send a
notification per command, and commands have timeout.

The timeout is only needed if there is no progress to report, i.e.
driver is waiting for something to happen.

> 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)

Powered by blists - more mailing lists