Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Tue, Feb 01, 2011 at 06:11:16AM +0100, David Miller wrote:
Jesper, could you please review this?
Looks good!
Acked-by: Jesper Nilsson jesper.nils...@axis.com
klist: Fix object alignment on 64-bit.
Commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b (klist.c: bit 0 in
pointer can't be used as flag) intended to make sure that all klist
objects were at least pointer size aligned, but used the constant 4
which only works on 32-bit.
Use sizeof(void *) which is correct in all cases.
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/include/linux/klist.h b/include/linux/klist.h
index e91a4e5..a370ce5 100644
--- a/include/linux/klist.h
+++ b/include/linux/klist.h
@@ -22,7 +22,7 @@ struct klist {
struct list_headk_list;
void(*get)(struct klist_node *);
void(*put)(struct klist_node *);
-} __attribute__ ((aligned (4)));
+} __attribute__ ((aligned (sizeof(void *;
#define KLIST_INIT(_name, _get, _put)
\
{ .k_lock = __SPIN_LOCK_UNLOCKED(_name.k_lock), \
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Tue, Jan 18, 2011 at 06:24:44AM +0100, David Miller wrote: From: Bernhard R. Link brl+ccmadn...@pcpool00.mathematik.uni-freiburg.de Date: Mon, 17 Jan 2011 15:39:54 +0100 * David Miller da...@davemloft.net [110117 07:07]: Ugh, and I just noticed that include/linux/klist.h does this fixed alignment of 4 too, where is this stuff coming from? It's wrong on 64-bit, at best. But I can't see the impetus behind doing this at all in the first place. Is that actually misaligned? Unless I still mix things up, that is in the struct thus should be fine (i.e. the d case in my example above). On CRIS, structs naturally align on a byte-boundary only. However, code using klists encodes a binary state in the lowest bit of klist pointers. So this assumes that the structures will be at least 2 byte aligned, which will not be true on CRIS. We have a lot of other code which uses this trick (encoding 1 or 2 bits of binary state into the lowest bits of a pointer) so I'm surprised this workaround isn't needed elsewhere for CRIS too. Surprisingly, we haven't found any other place where this is an issue for CRIS, either the code isn't used on CRIS, or the aligment is ensured by some other means (kmalloc for example). /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Mon, Jan 17, 2011 at 07:07:55AM +0100, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
[ Please, everyone, retain the full CC: on all replies, thanks. Some
people are replying only into the debian bug alias, and that loses
information and exposure for fixing this bug. ]
I think the problem we have here is that the _ftrace_events section is
not aligned sufficiently. That .align 4 mnemonic is a good indication
of this. It should at least 8 on sparc64.
I did some more research.
Although I've seen commentary to the contrary, in fact using a too-small
__attribute__((aligned())) directive will lower the alignment of data
members, and yes that means it will lower the alignemnt to be below the
natural and required alignment for the given type.
So if you have, on 64-bit:
struct foo {
void *bar;
};
static struct foo test __attribute__((__aligned__(4)));
The compiler will emit test with 4-byte alignment into the data
section, even though 8-byte alignment is required for test.bar
Assuming we wanted that to actually happen, the GCC manual is very
explicit to state that in order for this to work, such down-aligned
data structures must also use the packed attribute.
I think we want none of this, and I think we should elide the align
directives entirely, or at least fix them so we don't get unaligned
stuff on 64-bit.
Ugh, and I just noticed that include/linux/klist.h does this fixed
alignment of 4 too, where is this stuff coming from? It's
wrong on 64-bit, at best. But I can't see the impetus behind doing
this at all in the first place.
Oh, this is some CRIS thing, because it only byte aligns. See:
commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b
Author: Jesper Nilsson jesper.nils...@axis.com
Date: Wed Jan 14 11:19:08 2009 +0100
klist.c: bit 0 in pointer can't be used as flag
That's where the klist one comes from.
Yup, this one could instead be solved by introducing a flags field
in the struct, but that was considered a too large impact fix.
The ftrace ones come from:
commit 86c38a31aa7f2dd6e74a262710bf8ebf7455acc5
Author: Jeff Mahoney je...@suse.com
Date: Wed Feb 24 13:59:23 2010 -0500
tracing: Fix ftrace_event_call alignment for use with gcc 4.5
We really can't handle this that way, it's going to break stuff
on 64-bit systems at the very least.
How about we use __BIGGEST_ALIGNMENT__ or something arch-defined value
instead?
From CRIS-standpoint that would be fine.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
