linux-kernel - Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi

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: <20110119223339.GD23544@Krystal>
Date:	Wed, 19 Jan 2011 17:33:39 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	David Miller <davem@...emloft.net>
Cc:	rostedt@...dmis.org, richm@...elvet.org.uk, 609371@...s.debian.org,
	ben@...adent.org.uk, sparclinux@...r.kernel.org,
	linux-kernel@...r.kernel.org, fweisbec@...il.com, mingo@...hat.com
Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:
	Unknown relocation: 36

* David Miller (davem@...emloft.net) wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Date: Wed, 19 Jan 2011 17:13:27 -0500
> 
> > Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would
> > generate a unaligned access for a 32-bit aligned u64. Do you have examples in
> > mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK,
> > gcc treats u64 as two distinct reads on all 32-bit architectures.
> 
> Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI
> specifies that every structure is at least 8 byte aligned.

Ah, that's the answer I was looking for, thanks!

> 
> > gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using
> > gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, "packed"
> > generates aweful code, but that "packed, aligned(4 or 8)" generates pretty
> > decent code:
> 
> Amazing, if this works then do it.
> 
> But please document this fully with comments and such :-)

I will, I will! ;)

So I guess we go for the following. Is it verbose enough ?

/*
 * __u64_packed_aligned:
 *
 * Forces gcc to use the u64 type alignment, up-aligning or down-aligning the
 * target type if necessary. The memory accesses to the target structure are
 * efficient (does not require bytewise memory accesses) and the atomic pointer
 * update guarantees required by RCU are kept. u64 is considered as the largest
 * type that can generate a trap for unaligned accesses (u64 on sparc32 needs to
 * be aligned on 64-bit).
 *
 * Specifying both "packed" and "aligned" generates decent code (without the
 * bytewise memory accesses generated by simply using "packed"), and forces
 * gcc to down-align the structure alignment to the alignment of a u64 type.
 *
 * This alignment should be used for both structure definitions and declarations
 * (as *both* the type and variable attribute) when using the "section"
 * attribute to generate arrays of structures.
 */
#define __u64_packed_aligned \
        __attribute__((__packed__, __aligned__(__alignof__(long long))))

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/