linux-kernel - Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

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:   Thu, 4 May 2017 23:30:05 +0000
From:   Roy Pledge <roy.pledge@....com>
To:     Scott Wood <oss@...error.net>,
        Karim Eshapa <karim.eshapa@...il.com>
CC:     Claudiu Manoil <claudiu.manoil@....com>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck
 hacking jiffies.

On 5/4/2017 5:07 PM, Scott Wood wrote:
> On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote:
>> +	stop = jiffies + 10000;
>> +	/*
>> +	 * if MR was full and h/w had other FQRNI entries to produce, we
>> +	 * need to allow it time to produce those entries once the
>> +	 * existing entries are consumed. A worst-case situation
>> +	 * (fully-loaded system) means h/w sequencers may have to do 3-4
>> +	 * other things before servicing the portal's MR pump, each of
>> +	 * which (if slow) may take ~50 qman cycles (which is ~200
>> +	 * processor cycles). So rounding up and then multiplying this
>> +	 * worst-case estimate by a factor of 10, just to be
>> +	 * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
>> +	 * one entry at a time, so h/w has an opportunity to produce new
>> +	 * entries well before the ring has been fully consumed, so
>> +	 * we're being *really* paranoid here.
>> +	 */
> OK, upon reading this more closely it seems the intent was to delay for 10,000
> *processor cycles* and somehow that got turned into 10,000 jiffies (which is
> 40 seconds at the default Hz!).  We could just replace this whole thing with
> msleep(1) and still be far more paranoid than was originally intended.
>
> Claudiu and Roy, any comments?
Yes the timing here is certainly off, the code changed a few times since
the comment was originally written.
An msleep(1) seems reasonable here to me.

Roy
>
> -Scott
>
>