Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756446AbcJTEIZ (ORCPT ); Thu, 20 Oct 2016 00:08:25 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:35870 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753007AbcJTEIW (ORCPT ); Thu, 20 Oct 2016 00:08:22 -0400 Date: Thu, 20 Oct 2016 15:08:14 +1100 From: Nicholas Piggin To: Russell King - ARM Linux Cc: Arnd Bergmann , Michal Marek , Adam Borowski , Omar Sandoval , Linus Torvalds , adobriyan@gmail.com, sfr@canb.auug.org.au, viro@zeniv.linux.org.uk, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM Message-ID: <20161020150814.42951f61@roar.ozlabs.ibm.com> In-Reply-To: <20161019153159.GQ1041@n2100.armlinux.org.uk> References: <20161017065131.GA27863@angband.pl> <6556201.qTG4Pa4aHk@wuerfel> <3114442.xCAy34UQCk@wuerfel> <20161019153159.GQ1041@n2100.armlinux.org.uk> Organization: IBM X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3826 Lines: 93 On Wed, 19 Oct 2016 16:32:00 +0100 Russell King - ARM Linux wrote: > On Wed, Oct 19, 2016 at 05:02:55PM +0200, Arnd Bergmann wrote: > > On Wednesday, October 19, 2016 4:52:06 PM CEST Michal Marek wrote: > > > Dne 17.10.2016 v 14:26 Arnd Bergmann napsal(a): > > > > 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 'extern' declarations out of memset_io/memcpy_io > > > > to make them visible to the symbol version generator > > > > - 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. > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > > Hi Arnd, > > > > > > just to make sure I'm looking at the right code - is this based on the > > > patch by Nick here: https://patchwork.kernel.org/patch/9377783/? > > > > > > > (adding Russell to Cc, I missed him during my earlier mail, which > > is now archived at https://lkml.org/lkml/2016/10/17/356) > > I'm not in favour of this. > > +extern void mmioset(void *, unsigned int, size_t); > +extern void mmiocpy(void *, const void *, size_t); > + > #ifndef __ARMBE__ > static inline void memset_io(volatile void __iomem *dst, unsigned c, > size_t count) > { > - extern void mmioset(void *, unsigned int, size_t); > mmioset((void __force *)dst, c, count); > } > > The reason they're declared _within_ memset_io() is to prevent people > from using them by hiding their declaration. Moving them outside is > an open invitation to stupid people starting to use them as an "oh it > must be an official API". > > We know this happens, there's been a long history of this kind of stupid > in the ARM community, not only with cache flushing APIs, but also the > DMA APIs. > > The way the existing code is written is a completely valid way to hide > declarations from outside the intended caller's scope. > > We've been here many times, we've had many people doing this crap, so > I'm now at the point of NAKing changes which result in an increased > visibility to the rest of the kernel of symbols that should not be > used by stupid driver authors. > > Now, why do we have these extra functions when they're just aliased to > memset()/memcpy() - to avoid GCC optimising them because it thinks that > they're standard memset()/memcpy(). > > So overall this gets a NAK from me. Fair point, what about leaving those as they are, and also adding them to asm-prototypes.h protected with GENKSYMS ifdef? It's not beautiful, but still better than armksyms.c before Al's patches (or at least no worse). > Now, it would have _ALSO_ been nice to have been at least COPIED on the > original set of changes that caused the need for this change. I wasn't. > So I want to see the original set of changes reverted, because they're > clearly causing breakage. Let's revert them and then go through the > proper process of maintainer review, rather than bypassing maintainers > and screwing up architectures in the process. There really is no > excuse for this crap. You may have a point about improvement of the process. I wasn't involved in the original patches, but we did cc linux-arch when the .S CRC issue became known. However let's work on the assumption that they won't be reverted at this stage, and try to come up with something to fix it that you're happy with. Thanks, Nick