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: <063D6719AE5E284EB5DD2968C1650D6D0F6E784F@AcuExch.aculab.com>
Date:	Mon, 24 Mar 2014 12:33:18 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Ian Campbell' <Ian.Campbell@...rix.com>,
	Wei Liu <wei.liu2@...rix.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"paul.durrant@...rix.com" <paul.durrant@...rix.com>,
	"zoltan.kiss@...rix.com" <zoltan.kiss@...rix.com>,
	"edwin@...rok.net" <edwin@...rok.net>
Subject: RE: [PATCH net] xen-netback: disable rogue vif in kthread context

From: Ian Campbell
...
> > +		if (unlikely(vif->disabled) && netif_carrier_ok(vif->dev))
> 
> Perhaps consider extending the scope of the unlikely over the entire
> expression? (not that I expect it will matter much)

A lot of these 'unlikely' are as much a hint to the person
reading the code than to the compiler!

I found (with a much older gcc) that an overall 'unlikely' didn't
have the same effect as one on each part.
I also found that gcc ignored 'unlikely' if the 'else' branch is empty.

'if (unlikely(...)) continue' generated a backwards (predicted true)
conditional branch. I added an asm("comment " ## __LINE__) before
the continue to force a forwards condition branch to an unconditional
branch to the loop top.
(Yes - I did care about every clock in that code.)

	David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ