From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933207AbcAKN7v (ORCPT ); Mon, 11 Jan 2016 08:59:51 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:36013 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758735AbcAKN7r (ORCPT ); Mon, 11 Jan 2016 08:59:47 -0500 MIME-Version: 1.0 In-Reply-To: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> References: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> Date: Mon, 11 Jan 2016 14:59:46 +0100 Message-ID: Subject: Re: [PATCH v2 0/6] generic relative extable support From: Ard Biesheuvel To: Andrew Morton , 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" , "mingo@redhat.com" , Heiko Carstens , schwidefsky@de.ibm.com, Matt Turner , ink@jurassic.park.msu.ru, Richard Henderson , Tony Luck , "Yu, Fenghua" , Catalin Marinas , Will Deacon , Arnd Bergmann Cc: Helge Deller , Mark Rutland , Ard Biesheuvel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5 January 2016 at 16:19, Ard Biesheuvel wrote: > There are currently four architectures (x86, ia64, alpha and s390) whose > user-access exception tables are relative to the table entry address rather > than absolute. Each of these architectures has its own search_extable() and > sort_extable() implementation, which are not only mostly identical to each > other, but also deviate very little from the generic absolute implementations > in lib/extable.c that they override. > > So before making arm64 the fifth architecture that reimplements this, let's > refactor the existing code so that all of these architectures use common code > for searching and sorting the relative extables. Archs may set > ARCH_HAS_RELATIVE_EXTABLE to indicate that the table consists of a pair of > relative ints, and may define swap_ex_entry_fixup() if the fixup member needs > special treatment in the swapping step of the sorting routine (such as alpha). > [...] Now that I have collected acks for all the patches, I think this is good to go in. @Andrew: since this touches 5 different architectures, is this perhaps something that could go in via your tree after -rc1? (assuming that the s390 bugfix has been merged by then) Thanks, Ard. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Mon, 11 Jan 2016 14:59:46 +0100 Subject: [PATCH v2 0/6] generic relative extable support In-Reply-To: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> References: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 5 January 2016 at 16:19, Ard Biesheuvel wrote: > There are currently four architectures (x86, ia64, alpha and s390) whose > user-access exception tables are relative to the table entry address rather > than absolute. Each of these architectures has its own search_extable() and > sort_extable() implementation, which are not only mostly identical to each > other, but also deviate very little from the generic absolute implementations > in lib/extable.c that they override. > > So before making arm64 the fifth architecture that reimplements this, let's > refactor the existing code so that all of these architectures use common code > for searching and sorting the relative extables. Archs may set > ARCH_HAS_RELATIVE_EXTABLE to indicate that the table consists of a pair of > relative ints, and may define swap_ex_entry_fixup() if the fixup member needs > special treatment in the swapping step of the sorting routine (such as alpha). > [...] Now that I have collected acks for all the patches, I think this is good to go in. @Andrew: since this touches 5 different architectures, is this perhaps something that could go in via your tree after -rc1? (assuming that the s390 bugfix has been merged by then) Thanks, Ard. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ard Biesheuvel Date: Mon, 11 Jan 2016 13:59:46 +0000 Subject: Re: [PATCH v2 0/6] generic relative extable support Message-Id: List-Id: References: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> In-Reply-To: <1452007180-27411-1-git-send-email-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Morton , 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" , "mingo@redhat.com" , Heiko Carstens , schwidefsky@de.ibm.com, Matt Turner , ink@jurassic.park.msu.ru, Richard Henderson , Tony Luck , "Yu, Fenghua" , Catalin Marinas , Will Deacon , Arnd Bergmann Cc: Helge Deller , Mark Rutland , Ard Biesheuvel On 5 January 2016 at 16:19, Ard Biesheuvel wrote: > There are currently four architectures (x86, ia64, alpha and s390) whose > user-access exception tables are relative to the table entry address rather > than absolute. Each of these architectures has its own search_extable() and > sort_extable() implementation, which are not only mostly identical to each > other, but also deviate very little from the generic absolute implementations > in lib/extable.c that they override. > > So before making arm64 the fifth architecture that reimplements this, let's > refactor the existing code so that all of these architectures use common code > for searching and sorting the relative extables. Archs may set > ARCH_HAS_RELATIVE_EXTABLE to indicate that the table consists of a pair of > relative ints, and may define swap_ex_entry_fixup() if the fixup member needs > special treatment in the swapping step of the sorting routine (such as alpha). > [...] Now that I have collected acks for all the patches, I think this is good to go in. @Andrew: since this touches 5 different architectures, is this perhaps something that could go in via your tree after -rc1? (assuming that the s390 bugfix has been merged by then) Thanks, Ard.