[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110117.212444.193701604.davem@davemloft.net>
Date: Mon, 17 Jan 2011 21:24:44 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: brl+ccmadness@...ool00.mathematik.uni-freiburg.de
Cc: richm@...elvet.org.uk, 609371@...s.debian.org, ben@...adent.org.uk,
sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
rostedt@...dmis.org, fweisbec@...il.com, mingo@...hat.com,
Jesper.Nilsson@...s.com, jeffm@...e.com
Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:
Unknown relocation: 36
From: "Bernhard R. Link" <brl+ccmadness@...ool00.mathematik.uni-freiburg.de>
Date: Mon, 17 Jan 2011 15:39:54 +0100
> * David Miller <davem@...emloft.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.
--
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