netdev - Re: [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST

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] [day] [month] [year] [list]

Date:	Tue, 27 Oct 2015 23:02:25 +0000
From:	"Keller, Jacob E" <jacob.e.keller@...el.com>
To:	"dan.streetman@...onical.com" <dan.streetman@...onical.com>,
	"peter@...leysoftware.com" <peter@...leysoftware.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after
 RST

On Tue, 2015-10-27 at 18:45 -0400, Peter Hurley wrote:
> On 10/27/2015 02:35 PM, ND Linux CI Server wrote:
> > Greetings,
> > 
> > This email is automatically generated by ND's Linux Patch Testing
> > framework
> > based on aiaiai. I have performed some automatic testing of a patch
> > (series)
> > you submitted to intel-wired-lan@...ts.osuosl.org
> > 
> > The following contains output of any tests which failed to pass,
> > and might be
> > the result of developer error. The tests performed include but may
> > not be
> > limited to checkpatch.pl, bisection testing, compilation on a
> > default kernel
> > config, coccinelle scripts, cppcheck, and smatch.
> > 
> > If you have received this email in error, or believe that aiaiai
> > has detected a
> > false positive, please email Jacob Keller <jacob.e.keller@...el.com
> > >.
> 
> False positive.
> 
> As long as the delay is at least 1ms (which is guaranteed), slightly
> longer
> delays (relative to the existing reset delay of 100ms) are not
> harmful.
> 
> Use of usleep_range() would be unnecessary overkill for the purpose.
> 
> Regards,
> Peter Hurley


Feel free to ignore this then.

Regards,
Jake