Follow-up to remaining issue with alignment of __log_buf in printk.c

June 14th, 2012 - 03:20 pm ET by Robert Jarzmik | Report spam
Hi Stephen and others,

I have a XScale PXA based board with has the alignement issue which makes the
kernel trap during its early stage.

I wonder what is the status now, is there a fix available ?

I have tracked what happens on PXA. The pxa is an ARM v5TE chip. The new printk
version you submitted is translated to the following assembly on the line :
msg->ts_nsec = local_clock();
Into:
=> 0xc001bbe0 <log_store+496>: strd r0, [r4, r5]

In ARMv5, the "strd" assembly opcode expects the address to be 64bits aligned,
hence the bug.

Now the solutions I have seen so far in the mailing lists :
- #define LOG_ALIGN (__alignof__(u64))
Does always work.
- #define LOG_ALIGN (__alignof__(struct log))
Doesn't work with my toolchain, as __alignof__(struct log) is 4, not 8

What are you intending to do to solve the ARMv5 issue ? Are you waiting for
someone to submit a patch ?

Cheers.

Robert
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
email Follow the discussionReplies 3 repliesReplies Make a reply

Replies

#1 Stephen Warren
June 14th, 2012 - 03:40 pm ET | Report spam
On 06/14/2012 01:19 PM, Robert Jarzmik wrote:

Hi Stephen and others,

I have a XScale PXA based board with has the alignement issue which makes the
kernel trap during its early stage.

I wonder what is the status now, is there a fix available ?

I have tracked what happens on PXA. The pxa is an ARM v5TE chip. The new printk
version you submitted is translated to the following assembly on the line :
msg->ts_nsec = local_clock();
Into:
=> 0xc001bbe0 <log_store+496>: strd r0, [r4, r5]

In ARMv5, the "strd" assembly opcode expects the address to be 64bits aligned,
hence the bug.

Now the solutions I have seen so far in the mailing lists :
- #define LOG_ALIGN (__alignof__(u64))
Does always work.
- #define LOG_ALIGN (__alignof__(struct log))
Doesn't work with my toolchain, as __alignof__(struct log) is 4, not 8



Isn't that a bug in the toolchain; isn't the alignment of a struct
required to be the greatest alignment of any of its members? Otherwise,
this problem could arise with any usage of that struct.

I suppose this could be worked around with something like:

#define LOG_ALIGN max(__alignof__(struct log), __alignof__(u64))
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Similar topics