linux-kernel - RE: [PATCH RFC] liquidio: make timeout HZ independent

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 16 Dec 2016 17:53:27 +0000
From:   "Chickles, Derek" <Derek.Chickles@...ium.com>
To:     Nicholas Mc Guire <hofrat@...dl.org>
CC:     "Burla, Satananda" <Satananda.Burla@...ium.com>,
        "Manlunas, Felix" <Felix.Manlunas@...ium.com>,
        "Vatsavayi, Raghu" <Raghu.Vatsavayi@...ium.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH RFC] liquidio: make timeout HZ independent

> -----Original Message-----
> From: Nicholas Mc Guire [mailto:hofrat@...dl.org]
> Sent: Thursday, December 15, 2016 10:57 PM
> To: Chickles, Derek
> Cc: Burla, Satananda; Manlunas, Felix; Vatsavayi, Raghu;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Nicholas Mc Guire
> Subject: [PATCH RFC] liquidio: make timeout HZ independent
> 
> schedule_timeout_* takes a timeout in jiffies but the code currently is
> passing in a constant which makes this timeout HZ dependent, so pass it
> through msecs_to_jiffies() to fix this up.
> 
> Fixes: commit b0d66369edcd ("liquidio VF error handling")
> Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> ---
> 
> Problem found by coccinelle spatch
> 
> The current wait time can vary by a factor 10 depending on the HZ
> setting chose, which does not seem reasonable here.
> 
> The below patch sets the timeout to 100ms - it is though not clear
> if this is the intent or if it should be longer/shorter as it is not
> clear what HZ setting was assumed during design and used for testing.
> 
> This needs an ack by someone who knows the device and can confirm that
> 100ms is reasonable to wait for completion of in-flight requests.

Yes, 100ms was the intent here.

Thanks for catching this.

Derek