| 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
| ||
|
Message-ID: <20151127112025.GD20269@linux-mips.org> Date: Fri, 27 Nov 2015 12:20:26 +0100 From: Ralf Baechle <ralf@...ux-mips.org> To: Rasmus Villemoes <linux@...musvillemoes.dk> Cc: linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org Subject: Re: no-op delay loops On Fri, Nov 27, 2015 at 09:53:50AM +0100, Rasmus Villemoes wrote: > It seems that gcc happily compiles > > for (i = 0; i < 1000000000; ++i) ; > > into simply > > i = 1000000000; > > (which is then usually eliminated as a dead store). At least at -O2, and > when i is not declared volatile. So it would seem that the loops at > > arch/mips/pci/pci-rt2880.c:235 > arch/mips/pmcs-msp71xx/msp_setup.c:80 > arch/mips/sni/reset.c:35 > > actually don't do anything. (In the middle one, i is 'register', but > that doesn't change anything.) Is mips compiled with some special flags > that would make gcc actually emit code for the above? Thanks for reporting! GCC used to intentionally not eleminate empty loops. This has changed a while ago. Using volatile for the loop variable will result in atrocious code so should be avoided. One problem of these open coded loops is that it's not obvious how much delay was actually intended so when fixing this I will have to do a bit of precission guessing ;-) Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists