Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4488160imm; Mon, 15 Oct 2018 16:04:30 -0700 (PDT) X-Google-Smtp-Source: ACcGV62cR2JE1eyrR5JUq9yNVeq2j0UzIGCRrQInuRtya3sjd5y2WUi6N4A+AV8c3X3NaaujiODJ X-Received: by 2002:a17:902:b7cb:: with SMTP id v11-v6mr18945584plz.79.1539644670050; Mon, 15 Oct 2018 16:04:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539644670; cv=none; d=google.com; s=arc-20160816; b=VJPXYvssij+Uy8vyc7Aa5B7t6m6UmOv4we8si57eoNc1UFoavTLbGEZS47GgOmRtvp lFyoEgs8Vk+XxMSm9jha8NwwAiZD7iRTiO/TEjzA+hyn/+4Bgz62H/LQW/CBt5aBYBzq NUTUE2zHY99QE0Y1w+zAP+abK1JDVKpIVcy1lpjBcS6b+ZYovn1Id03dKBXlE/2jugF/ eLK5I/FK3k4Xzu/TRufKAyaOEx/VF1axwXqUhObiK01CwTf6+My9Xa8H7wss75k2Mopc d8ixPX4wOOb/lEOrTYyHbbdOr+A/iBHXSlphPvut97xJF0j9zFi4/eeeKcntqNpteYbT 7mRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LVVo2yhtZsNMoa6xptbobUCvAJzCgQ4JTayJBsNjOck=; b=WjkTTzr/9y5dHGLkfNrRcPIJyswtKpEIRwiKawYdeLaSQnEh2dHpryNvUtCV8ugsqt PJtb/LozaQCoJHtE2gbOX68kqKiYTXkn7Aj0s12Pk+aB9oIADjELHC0wAy/lCxX6FdOl chx/0tRygpd2SPW7mMk96yyeIHRwQHn11iFxZgivhIJLBsrTCUXQ347fOij6CqclNvdV Cd+Mid1MPNjYQIhbV6qGrDbSonnh1xsDg7DOU/gqcOVKEF09GOKOgbWCtT/WBV/GbnqN FzUHug/+fwkzuM2Zj2BPEZRvoYxQNh1avy+oaxiVrwDMFHOLMu9B+lKKlLxDhrAqrV0a 54Pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=gQmt+Y1a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w3-v6si11876257pgk.176.2018.10.15.16.04.14; Mon, 15 Oct 2018 16:04:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=gQmt+Y1a; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727130AbeJPGvF (ORCPT + 99 others); Tue, 16 Oct 2018 02:51:05 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:48532 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726877AbeJPGvF (ORCPT ); Tue, 16 Oct 2018 02:51:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LVVo2yhtZsNMoa6xptbobUCvAJzCgQ4JTayJBsNjOck=; b=gQmt+Y1ayxY6xzV5Yb8ADwFCm 3O2OQwSW5LU6+cr22lyzpiduxH4ZPGUfXmIQ9C87g9+WdORu8eKFftWQR5j+LYpp7NUYcmVxasBzz uWHkedBFZhfsbuqRlQ3UKZOQFqA6ZEyVOwGuZxWujUZju+A3PO5wkOgWMvWh5o3MpgXC0=; Received: from n2100.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:34285) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gCBtg-0003Ct-JG; Tue, 16 Oct 2018 00:03:36 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1gCBtZ-0008DR-TO; Tue, 16 Oct 2018 00:03:30 +0100 Date: Tue, 16 Oct 2018 00:03:27 +0100 From: Russell King - ARM Linux To: Stefan Agner Cc: raj.khem@gmail.com, ulli.kroll@googlemail.com, joel@jms.id.au, nico@linaro.org, arnd@arndb.de, linus.walleij@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: copypage-fa: add kto and kfrom to input operands list Message-ID: <20181015230327.GD30658@n2100.armlinux.org.uk> References: <20181015221629.13924-1-stefan@agner.ch> <20181015222302.GZ30658@n2100.armlinux.org.uk> <26d465580722c7f65b6916e96e283967@agner.ch> <20181015224614.GB30658@n2100.armlinux.org.uk> <2802c0e549149872aa58da5fb54471fc@agner.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2802c0e549149872aa58da5fb54471fc@agner.ch> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 16, 2018 at 12:52:58AM +0200, Stefan Agner wrote: > On 16.10.2018 00:46, Russell King - ARM Linux wrote: > > On Tue, Oct 16, 2018 at 12:39:54AM +0200, Stefan Agner wrote: > >> On 16.10.2018 00:23, Russell King - ARM Linux wrote: > >> > On Tue, Oct 16, 2018 at 12:16:29AM +0200, Stefan Agner wrote: > >> >> When functions incoming parameters are not in input operands list gcc > >> >> 4.5 does not load the parameters into registers before calling this > >> >> function but the inline assembly assumes valid addresses inside this > >> >> function. This breaks the code because r0 and r1 are invalid when > >> >> execution enters v4wb_copy_user_page () > >> > > >> > NAK. Naked functions must never be inlined. Please add a "noinline" > >> > attribute to the function rather than making things more complex. > >> > > >> > >> To be honest, I did not put much thought into this commit since it is > >> just doing to copypage-fa.c what 9a40ac86152c ("ARM: 6164/1: Add kto and > >> kfrom to input operands list.") has been done to the other copypage > >> implementations... > >> > >> [adding Khem] > >> > >> > The GCC manual states: > >> > > >> > `naked' > >> > Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX > >> > and SPU ports to indicate that the specified function does not > >> > need prologue/epilogue sequences generated by the compiler. It is > >> > up to the programmer to provide these sequences. The only > >> > ^^^^^^^^ > >> > statements that can be safely included in naked functions are > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > `asm' statements that do not have operands. All other statements, > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > including declarations of local variables, `if' statements, and so > >> > forth, should be avoided. Naked functions should be used to > >> > implement the body of an assembly function, while allowing the > >> > compiler to construct the requisite function declaration for the > >> > assembler. > >> > > >> > The 'I' attribute is fine here because it is a constant that is not > >> > allowed to be in a register (and hence has no code generation side > >> > effects.) > >> > > >> > Adding operands for the input parameters, however, isn't going to > >> > work around the fact that _this_ assembly is written to be out of > >> > line and so it must never be inlined by the compiler. > >> > >> I briefly looked at a disassembled version after applying both patches, > >> it indeed leads to inlining. However, the code seems to be working > >> (thanks to asm volatile?)... > > > > Apart from v4wb_copy_user_page() and mc_copy_user_page(), how is > > Clang inlining these static functions that are only used through > > function pointers? > > I only looked at copypage-xscale.c (the mc_copy_user_page() case)... The two I mention are different from the rest, because they are used from other functions within the same file. The rest are all used through function pointers and should, therefore, never be inlined. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up