Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:Unknown relocation: 36

[Jesper Nilsson]

On Tue, Jan 18, 2011 at 06:24:44AM +0100, David Miller wrote:
> From: "Bernhard R. Link" <brl+ccmadness@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: Mon, 17 Jan 2011 15:39:54 +0100
> 
> > * David Miller <davem@xxxxxxxxxxxxx> [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.nilsson@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/