From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Date: Wed, 27 Jan 2016 19:46:11 +0000 Subject: Re: [PATCH v2 resend 6/6] arm64: switch to relative exception tables Message-Id: <20160127114611.25531afcfabf03febc134b48@linux-foundation.org> List-Id: References: <1453892123-17973-1-git-send-email-ard.biesheuvel@linaro.org> <1453892123-17973-7-git-send-email-ard.biesheuvel@linaro.org> <20160127113548.d4f2f2a7029b3b89f0e596da@linux-foundation.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ard Biesheuvel Cc: linux-alpha@vger.kernel.org, "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-ia64@vger.kernel.org" , linux-s390@vger.kernel.org, "x86@kernel.org" , "hpa@zytor.com" , Heiko Carstens , Richard Henderson , Tony Luck , Will Deacon , Helge Deller On Wed, 27 Jan 2016 20:39:23 +0100 Ard Biesheuvel wrote: > On 27 January 2016 at 20:35, Andrew Morton wrote: > > On Wed, 27 Jan 2016 11:55:23 +0100 Ard Biesheuvel wrote: > > > >> Instead of using absolute addresses for both the exception location > >> and the fixup, use offsets relative to the exception table entry values. > >> Not only does this cut the size of the exception table in half, it is > >> also a prerequisite for KASLR, since absolute exception table entries > >> are subject to dynamic relocation, which is incompatible with the sorting > >> of the exception table that occurs at build time. > >> > >> This patch also introduces the _ASM_EXTABLE preprocessor macro (which > >> exists on x86 as well) and its _asm_extable assembly counterpart, as > >> shorthands to emit exception table entries. > > > > checkpatch speaketh truth: > > > > ERROR: #define of 'ARCH_HAS_RELATIVE_EXTABLE' is wrong - use Kconfig variables or standard guards instead > > #113: FILE: arch/arm64/include/asm/uaccess.h:56: > > That may be true, but it extends an established pattern of #defines in > the various uaccess.h versions, i.e., ARCH_HAS_SORT_EXTABLE, and > ARCH_HAS_SEARCH_EXTABLE True. But now we have two things to fix, not one ;) Whatever. Later.