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: Sun, 20 Nov 2016 13:21:27 +0000 From: Russell King - ARM Linux <linux@...linux.org.uk> To: Nicholas Piggin <npiggin@...il.com> Cc: Arnd Bergmann <arnd@...db.de>, Michal Marek <mmarek@...e.com>, Adam Borowski <kilobyte@...band.pl>, Omar Sandoval <osandov@...ndov.com>, Linus Torvalds <torvalds@...ux-foundation.org>, adobriyan@...il.com, sfr@...b.auug.org.au, viro@...iv.linux.org.uk, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org Subject: Re: [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM On Tue, Oct 25, 2016 at 07:32:00PM +1100, Nicholas Piggin wrote: > On Mon, 24 Oct 2016 17:05:26 +0200 > Arnd Bergmann <arnd@...db.de> wrote: > > > This adds an asm/asm-prototypes.h header for ARM to fix the > > broken symbol versioning for symbols exported from assembler > > files. > > > > In addition to the header, we have to do these other small > > changes: > > > > - move the exports from bitops.h to {change,clear,set,...}bit.S > > - move the exports from csumpartialgeneric.S into the files > > including it > > > > I couldn't find the correct prototypes for the compiler builtins, > > so I went with the fake 'void f(void)' prototypes that we had > > before. > > > > This leaves the mmioset/mmiocpy function for now, as it's not > > obvious how to best handle them. > > > This looks nicer. I like variant B because it keeps the GENKSYMS cruft to > a single location, but either one isn't too bad. > > I'd like to get moving on this, so let's at least get the generic kbuild > change merged. In the end, the kbuild code does not prevent a maintainer > from putting their EXPORT_SYMBOL in whatever location they like, so there > is no reason not to merge it (certainly there will be archs that do use > it). > > Michal, what's your thoughts? If you merge my patch 2/2 and skip 1/2, it > should not give any new build warnings or errors, so then arch patches can > go via arch trees. 1/2 could go in after everyone is up to date. So what's the conclusion on this? I've just had a failure due to CONFIG_TRIM_UNUSED_KSYMS reported on ARM, and it looks like (at least some of) patch 1 could resolve it. Do we need to split patch 1? Has any of these patches been committed yet? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Powered by blists - more mailing lists