Pete Zaitcev wrote on Monday, December 11, 2006 5:29 PM > On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote: > > > I'm shocked memcpy() introduces 8-byte stores that violate architecture > > alignment rules. Is there any chance this a bug in ia64's memcpy() > > implementation? I've tried to read it but since I'm not familiar with > > ia64 asm I can't make out significant parts of it in > > arch/ia64/lib/memcpy.S. > > The arch/ia64/lib/memcpy.S is probably fine, it must be gcc doing > an inline substitution of a well-known function.
arch/ia64/lib/memcpy.S is fine because it does alignment check at the very beginning of the function and depends on the alignment of dst/src alignment, it does different thing. The unaligned access is coming from gcc inlined version of memcpy. But looking deeply, memory allocation for proc_event in proc_for_connector doesn't looked correct at all: In drivers/connector/cn_proc.c: #define CN_PROC_MSG_SIZE (sizeof(struct cn_msg) + sizeof(struct proc_event)) void proc_fork_connector(struct task_struct *task) { struct cn_msg *msg; struct proc_event *ev; __u8 buffer[CN_PROC_MSG_SIZE]; You can't do that because gcc assumes struct proc_event aligns on certain boundary. Doing fancy hand crafting like that breaks code generated by gcc. - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/