[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160422231503.GE17051@piout.net>
Date: Sat, 23 Apr 2016 01:15:03 +0200
From: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Dave Martin <Dave.Martin@....com>,
Olof Johansson <olof@...om.net>,
Doug Anderson <dianders@...omium.org>,
Heiko Stuebner <heiko@...ech.de>, Russ Dill <Russ.Dill@...com>,
Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: [PATCH 1/2] ARM: PIE infrastructure
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
Powered by blists - more mailing lists