| 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
| ||
|
Date: Fri, 9 May 2014 14:22:52 +0200 (CEST) From: Michael Matz <matz@...e.de> To: Pavel Machek <pavel@....cz> cc: Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org, jirislaby@...il.com, Vojtech Pavlik <vojtech@...e.cz>, Jiri Kosina <jkosina@...e.cz>, Udo Seidel <udoseidel@....de> Subject: Re: kgr: dealing with optimalizations? (was Re: [RFC 06/16] kgr: add Documentat)ion Hi, On Fri, 9 May 2014, Pavel Machek wrote: > Ok, one big question: you are replacing single functions, and assume > that's ok, right? > > But ... is it ok? gcc is allowed to do optimalization on whole source > file (and whole source tree with LTO). How do you prevent situation > where changing function foo() breaks optimalization in function bar()? If such situation (behaviour changes with optimization) happens it's either compiler or a source bug, so is of no direct concern to kgraft. If you want to exchange an inlined function foo you of course have to take care of actually exchanging all functions into which foo was inlined. For that you need the inline tree for all kernels for which you want to support kgrafting. > Is turning off inter-procedural and inter-module optimalizations needed > for kgraft to work? No. Ciao, Michael. -- 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