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]
Message-ID: <1493932034.25397.37.camel@buserror.net>
Date:   Thu, 04 May 2017 16:07:14 -0500
From:   Scott Wood <oss@...error.net>
To:     Karim Eshapa <karim.eshapa@...il.com>
Cc:     claudiu.manoil@....com, roy.pledge@....com,
        colin.king@...onical.com, linuxppc-dev@...ts.ozlabs.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck
 hacking jiffies.

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?

-Scott

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ