netdev - RE: [PATCH 1/2] rtlwifi: Fix improve function 'rtl_addr

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]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CCD6823@AcuExch.aculab.com>
Date:	Thu, 4 Feb 2016 16:02:01 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Larry Finger' <Larry.Finger@...inger.net>,
	ByeoungWook Kim <quddnr145@...il.com>
CC:	"kvalo@...eaurora.org" <kvalo@...eaurora.org>,
	"chaoming_li@...lsil.com.cn" <chaoming_li@...lsil.com.cn>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] rtlwifi: Fix improve function 'rtl_addr_delay()' in
 core.c

From: Larry Finger
> Sent: 04 February 2016 15:44
> On 02/04/2016 03:48 AM, David Laight wrote:
> > From: Larry Finger
> >> Sent: 03 February 2016 19:45
> > ...
> >> The performance will depend on where you satisfy the condition. All switch cases
> >> have the same execution time, but in the if .. else if .. else form, the earlier
> >> tests execute more quickly. I'm not sure that one can make any blanket statement
> >> about performance. Certainly, the switch version will be larger. For a switch
> >> with 8 cases plus default, the object code if 43 bytes larger than the nested
> >> ifs in a test program that I created. That is a significant penalty.
> >
> > There is also the penalty of the (likely) data cache miss reading the jump table.
> > But given this code is all about generating a variable delay the execution
> > speed is probably irrelevant.
> >
> > It would be much more interesting if the delay could be changed for sleeps.
> 
> Unfortunately, sleeping is not possible for the routines that call rtl_addr_delay().

I hope none of my systems ever busy-delay for 50ms.

Actually possibly just as troublesome is udelay(1).

I presume this is used after a 'hardware' write in order to meet a minimum
pulse width (or an inter-cycle recovery time).

Unfortunately the initial write cycle will almost certainly be 'posted' so
may not actually be seen by the target until some time later.

This means that although the cpu delayed 1us, the target hardware might
see the second access back to back with the first one.

Forcing the posted write to complete almost certainly involves reading
back from exactly the same physical address (possibly after some sync
instruction(s)).

	David