Thanks for the report.
AFAICT it's this line of mm/shmem.c:
2356 inode = shmem_get_inode(sb, S_IFDIR | sbinfo->mode, 0,
VM_NORESERVE );
and the loading of sbinfo->mode. It fits with the offset 0x3c(%esi) ==
the address reported by kmemcheck and the offset of ->mode:
(gdb) p &((struct shmem_sb_info *) 0).mode
$1 = (mode_t *) 0x3c
Looking for the definition of mode_t, it seems to be defined in x86
sources as unsigned short:
arch/x86/include/asm/posix_types_32.h:11:typedef unsigned short __kernel_mode_t;
include/linux/types.h:typedef __kernel_mode_t mode_t;
And the load was clearly 32-bit (kmemcheck said so) and in my assembly
dump it is also so.
As I said before, I really don't like the solution of sprinkling the
kmemcheck annotations all over the place to cover up field padding
inside structs, not in the least because they confuse more than they
help, and they are not maintainable -- when somebody changes the
struct definitions, anything may happen to the field layout, and then
the annotation may have to change too. And it's not exactly obvious.
I still vote for patching gcc as the long-term solution. There is
-fmudflap, there is -fstack-protector, why not a -fsacred-padding? Of
course it has to be implemented too...