lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Jun 2015 14:30:40 -0400
From:	David Long <dave.long@...aro.org>
To:	Rob Herring <robherring2@...il.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Anton Blanchard <anton@...ba.org>,
	Behan Webster <behanw@...verseincode.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Eric Paris <eparis@...hat.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Ingo Molnar <mingo@...hat.com>,
	Jan Willeke <willeke@...ibm.com>,
	Kees Cook <keescook@...omium.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nikolay Borisov <Nikolay.Borisov@....com>,
	Oleg Nesterov <oleg@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Richard Kuo <rkuo@...eaurora.org>,
	Robert Richter <rric@...nel.org>,
	Roland McGrath <roland@...k.frob.com>,
	Russell King <linux@....linux.org.uk>,
	Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-hexagon@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-s390@...r.kernel.org, SH-Linux <linux-sh@...r.kernel.org>,
	linux390@...ibm.com, linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch
 to common include file

On 06/16/15 09:17, Rob Herring wrote:
> On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@...aro.org> wrote:
>> From: "David A. Long" <dave.long@...aro.org>
>>
>> The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API
>>   feature and has identical definitions in four different arch ptrace.h
>> include files. It seems unlikely that definition would ever need to be
>> changed regardless of architecture so lets move it into
>> include/linux/ptrace.h.
>>
>> Signed-off-by: David A. Long <dave.long@...aro.org>
>> ---
>>   arch/arm/kernel/ptrace.c     | 5 -----
>>   arch/powerpc/kernel/ptrace.c | 5 -----
>>   arch/sh/include/asm/ptrace.h | 5 -----
>>   arch/x86/kernel/ptrace.c     | 5 -----
>>   include/linux/ptrace.h       | 9 +++++++++
>>   5 files changed, 9 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
>> index ef9119f..fb45cf1 100644
>> --- a/arch/arm/kernel/ptrace.c
>> +++ b/arch/arm/kernel/ptrace.c
>> @@ -59,11 +59,6 @@
>>   #define BREAKINST_THUMB        0xde01
>>   #endif
>>
>> -struct pt_regs_offset {
>> -       const char *name;
>> -       int offset;
>> -};
>> -
>>   #define REG_OFFSET_NAME(r) \
>>          {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
>>   #define REG_OFFSET_END {.name = NULL, .offset = 0}
>
> Can't you also move these? ARM is complicated with the "ARM_"
> prefixing, but the others appear to be the same. Maybe you can remove
> the prefix or redefine the macro for ARM.
>
> Rob
>

That would mandate that all the architecture-specific pt_regs structures 
would have to use a top-level named field for each named register.  That 
seems to me like an unnecessary restriction when the point of 
regs_offset_table is to provide the offset of the register inside an 
arbitarily complex pt_regs struct.  The often redundant definition of 
these two macros doesn't seem to me that high a price for that.

-dl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ