linux-kernel - RE: bit fields && data tearing

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]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17488265@AcuExch.aculab.com>
Date:	Fri, 5 Sep 2014 12:37:17 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Peter Hurley' <peter@...leysoftware.com>,
	"'paulmck@...ux.vnet.ibm.com'" <paulmck@...ux.vnet.ibm.com>
CC:	Jakub Jelinek <jakub@...hat.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	Mikael Pettersson <mikpelinux@...il.com>,
	"Oleg Nesterov" <oleg@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Tony Luck <tony.luck@...el.com>,
	Paul Mackerras <paulus@...ba.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"Miroslav Franc" <mfranc@...hat.com>,
	Richard Henderson <rth@...ddle.net>,
	"linux-arm@...r.kernel.org" <linux-arm@...r.kernel.org>
Subject: RE: bit fields && data tearing

From: Peter Hurley
> [ +cc linux-arm ]
> 
> Hi David,
> 
> On 09/05/2014 04:30 AM, David Laight wrote:
> > I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> > It does this because of the more limited range of the offsets for the 16bit access.
> > OTOH I don't know if it ever did this for writes - so it may be moot.
> 
> Can you recall the particulars, like what ARM config or what code?
> 
> I tried an overly-simple test to see if gcc would bump up to the word load for
> the 12-bit offset mode, but it stuck with register offset rather than immediate
> offset. [I used the compiler options for allmodconfig and a 4.8 cross-compiler.]
> 
> Maybe the test doesn't generate enough register pressure on the compiler?

Dunno, I would have been using a much older version of the compiler.
It is possible that it doesn't do it any more.
It might only have done it for loads.

The compiler used to use misaligned 32bit loads for structure
members on large 4n+2 byte boundaries as well.
I'm pretty sure it doesn't do that either.

There have been a lot of compiler versions since I was compiling
anything for arm.

	David

> Regards,
> Peter Hurley
> 
> #define ARRAY_SIZE(x)  (sizeof(x)/sizeof((x)[0]))
> 
> struct x {
> 	long unused[64];
> 	short b[12];
> 	int unused2[10];
> 	short c;
> };
> 
> void store_c(struct x *p, short a[]) {
> 	int i;
> 
> 	for (i = 0; i < ARRAY_SIZE(p->b); i++)
> 		p->b[i] = a[i];
> 	p->c = 2;
> }
> 
> 
> void store_c(struct x *p, short a[]) {
>    0:	e1a0c00d 	mov	ip, sp
>    4:	e3a03000 	mov	r3, #0
>    8:	e92dd800 	push	{fp, ip, lr, pc}
>    c:	e24cb004 	sub	fp, ip, #4
> 	int i;
> 
> 	for (i = 0; i < ARRAY_SIZE(p->b); i++)
> 		p->b[i] = a[i];
>   10:	e191c0b3 	ldrh	ip, [r1, r3]
>   14:	e0802003 	add	r2, r0, r3
>   18:	e2822c01 	add	r2, r2, #256	; 0x100
>   1c:	e2833002 	add	r3, r3, #2
>   20:	e3530018 	cmp	r3, #24
>   24:	e1c2c0b0 	strh	ip, [r2]
>   28:	1afffff8 	bne	10 <store_c+0x10>
> 	p->c = 2;
>   2c:	e3a03d05 	mov	r3, #320	; 0x140
>   30:	e3a02002 	mov	r2, #2
>   34:	e18020b3 	strh	r2, [r0, r3]
>   38:	e89da800 	ldm	sp, {fp, sp, pc}