Re: 2.6.35 regression

[Sam Ravnborg]

> 
> 		if (start->name && !strcmp(start->name + 3, str + 3))
> 			return start;
> 
> Now the "start" is iterating from: 
> 
> 	start = (struct syscall_metadata *)__start_syscalls_metadata;
> 	stop = (struct syscall_metadata *)__stop_syscalls_metadata;
> 
> 
> If for some reason, gcc did not link the metadata in a nice array,
> this could cause the start to index incorrectly, which would
> make the "start->name" reference be something pointing to left field.

In vmlinux.lds.h we have the following code:
#define TRACE_SYSCALLS() VMLINUX_SYMBOL(__start_syscalls_metadata) = .; \
                         *(__syscalls_metadata)                         \
                         VMLINUX_SYMBOL(__stop_syscalls_metadata) = .;

But there is nothing that guarantee that
__syscalls_metadata starts at the address
assigned to __start_syscalls_metadata.

The will align __syscalls_metadata accoding to the
largest member in that section.

We need to do one of two things:
1) Make sure __start_syscalls_metadata is properly aligned
2) or make the code robust against misaligned symbols.

> 
> Zeev, can you try to reproduce it with gcc 4.4.
> 
> And for now could you send me the output of this:
> 
>  objdump -Dr --start-addr 0x`nm vmlinux | grep __start_syscalls_metadata | cut -d' ' -f 1` \
>     --stop-addr 0x`nm vmlinux | grep __stop_syscalls_metadata | cut -d' ' -f 1` vmlinux
> 
This output would be great to have just to check if my assumption above is correct.

	Sam
--
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/