Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753545AbcDVXPS (ORCPT ); Fri, 22 Apr 2016 19:15:18 -0400 Received: from down.free-electrons.com ([37.187.137.238]:53640 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752245AbcDVXPP (ORCPT ); Fri, 22 Apr 2016 19:15:15 -0400 Date: Sat, 23 Apr 2016 01:15:03 +0200 From: Alexandre Belloni To: Russell King - ARM Linux Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Dave Martin , Olof Johansson , Doug Anderson , Heiko Stuebner , Russ Dill , Nicolas Ferre Subject: Re: [PATCH 1/2] ARM: PIE infrastructure Message-ID: <20160422231503.GE17051@piout.net> References: <1459668234-16033-1-git-send-email-alexandre.belloni@free-electrons.com> <1459668234-16033-2-git-send-email-alexandre.belloni@free-electrons.com> <20160404100052.GS19428@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160404100052.GS19428@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1323 Lines: 29 On 04/04/2016 at 11:00:52 +0100, Russell King - ARM Linux wrote : > > + /* Copy chunk specific code/data */ > > + fncpy((char *)chunk->addr, code_start, code_sz); > > Sorry, NAK. This abuses fncpy(). There is extensive documentation on > the proper use of this in asm/fncpy.h, and anything that does not > conform, or which uses memcpy() to copy functions, gets an immediate > NAK from me. fncpy() exists to avoid people doing broken things, and > it's written in such a way to help people get it right. Well, do you want me to iterate and use fncpy on all the functions from the generated binary? I'm not sure this is necessary as the generated binary is self contained and doing so will force me to also ensure the offsets are kept the same. Doing only one copy is much more convenient. However, I still need to ensure the destination address is properly 8-byte aligned and the flush_icache_range(). I understand this is abusing fncpy() but it does want I need (still, I'm planning to avoid the BUG() by always passing a properly aligned destination address). I've fixed the issue with big endian that was reported byt the kbuild test robot and I'd like a bit more advice on how to go forward, thanks! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com