netdev - RE: [PATCH net] xen-netback: disable rogue vif in kthread context

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:	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