linux-kernel - Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file

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, 22 Jul 2015 00:46:47 -0400
From:	David Long <dave.long@...aro.org>
To:	Michael Ellerman <michael@...erman.id.au>
CC:	Rob Herring <robherring2@...il.com>,
	"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>,
	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/29/15 23:29, Michael Ellerman wrote:
> On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
>> 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:
>>>>
>>>>    #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.
>>
>> That would mandate that all the architecture-specific pt_regs structures
>> would have to use a top-level named field for each named register.
>
> Why does it mandate that?
>
> See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
> then a different macro for the array elements:
>
>    #define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
>    #define GPR_OFFSET_NAME(num)	\
>    	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
>
>    static const struct pt_regs_offset regoffset_table[] = {
>    	GPR_OFFSET_NAME(0),
>    	GPR_OFFSET_NAME(1),
>    	GPR_OFFSET_NAME(2),
>    	GPR_OFFSET_NAME(3),
>    	...
>    	REG_OFFSET_NAME(nip),
>    	REG_OFFSET_NAME(msr),
>
>
> So I don't see why REG_OFFSET_NAME couldn't be common.
>

Sorry for the delay in responding to this.

OK, so you're saying architectures that don't want this constraint can 
make their own macro.  Seems to make this whole exercise slightly less 
useful, but whatever.

I see three ways to go here:

1) Leave it as is.
2) Force all architectures to use a common definition.
3) Provide a common definition that all architectures (except "arm") 
currently using this functionality will use.

I have a v2 patch to implement #3, ready to post.  Do we think this is 
the way to go? I don't like #2 because I really don't want to rename all 
uses of the current register fields for arm since this is 
architecture-specific code to begin with and since it affects code in 39 
arm source files.

> cheers
>


Thanks,
-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/