2010-01-25 17:18:10

by Daniel J Blueman

[permalink] [raw]
Subject: [2.6.32.3] potentially uninitialised field in nfs_atomic_lookup...

When booting with 2.6.32.3 x86-64 with a debug configuration including
kmemcheck activated, I'm seeing bytes reported as uninitialised [1]
(here with value 0x33).

This is with automount and NFS4 [2] and reproduces consistently; it
appears to not be structure padding.

What additional information would help on this?

Daniel

--- [1]

WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
(ffff88016cc180c8)

07000000000000003333333333333333808d7e6d0188ffff988d7e6d0188ffff

i i i i i i i i u u u u u u u u i i i i i i i i i i i i i i i i



Modules linked in: nfs lockd nfs_acl auth_rpcgss netconsole configfs
autofs4 sunrpc af_packet ipv6 msr binfmt_misc dm_mod nvram evdev
psmouse rtc_cmos rtc_core rtc_lib e1000e piix pata_acpi
ide_pci_generic ata_generic rng_core ext3 jbd mbcache uhci_hcd
ohci_hcd ehci_hcd usbcore [last unloaded: microcode]

[<ffffffffa0236d2e>] nfs_atomic_lookup+0xce/0x110 [nfs]

[<ffffffff8113e13a>] do_lookup+0x1da/0x220

[<ffffffff8113e5c0>] __link_path_walk+0x440/0x760

[<ffffffff8113e937>] path_walk+0x57/0xb0

[<ffffffff8113e9fa>] vfs_path_lookup+0x6a/0xe0

[<ffffffffa023f370>] nfs_follow_remote_path+0x50/0x150 [nfs]

[<ffffffffa023fe97>] nfs4_try_mount+0x77/0xd0 [nfs]

[<ffffffffa024107b>] nfs4_get_sb+0x13b/0x320 [nfs]

[<ffffffff81134e18>] vfs_kern_mount+0x58/0xe0

[<ffffffff81134f0e>] do_kern_mount+0x4e/0x110

[<ffffffff8114dd06>] do_mount+0x546/0x7c0

[<ffffffff8114e00a>] sys_mount+0x8a/0xd0

[<ffffffff8100be2b>] system_call_fastpath+0x16/0x1b

[<ffffffffffffffff>] 0xffffffffffffffff


--- [2]

auto.direct /net/home autofs
rw,relatime,fd=5,pgrp=4013,timeout=300,minproto=5,maxproto=5,direct 0
0
filer:/home /net/home nfs4
rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=65535,timeo=600,retrans=3,sec=sys,clientaddr=172.16.0.130,addr=172.16.0.110
0 0

--- [3]

/net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1044
3cf1: 48 8b 5d e8 mov -0x18(%rbp),%rbx
3cf5: 4c 8b 65 f0 mov -0x10(%rbp),%r12
3cf9: 48 89 c8 mov %rcx,%rax
3cfc: 4c 8b 6d f8 mov -0x8(%rbp),%r13
3d00: c9 leaveq
3d01: c3 retq
/net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1022
3d02: 83 f8 ec cmp $0xffffffffffffffec,%eax
3d05: 74 19 je 3d20 <nfs_atomic_lookup+0xc0>
3d07: 83 f8 fe cmp $0xfffffffffffffffe,%eax
3d0a: 74 5e je 3d6a <nfs_atomic_lookup+0x10a>
3d0c: 83 f8 d8 cmp $0xffffffffffffffd8,%eax
3d0f: 90 nop
3d10: 75 df jne 3cf1 <nfs_atomic_lookup+0x91>
/net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1031
3d12: f6 83 8a 00 00 00 02 testb $0x2,0x8a(%rbx)
3d19: 75 d6 jne 3cf1 <nfs_atomic_lookup+0x91>
3d1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
/net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1043
3d20: 48 89 da mov %rbx,%rdx
3d23: 4c 89 e6 mov %r12,%rsi
3d26: 4c 89 ef mov %r13,%rdi
3d29: e8 22 fd ff ff callq 3a50 <nfs_lookup>
3d2e: 48 89 c1 mov %rax,%rcx <----
3d31: eb be jmp 3cf1 <nfs_atomic_lookup+0x91>
/net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1014
3d33: 31 f6 xor %esi,%esi
3d35: 4c 89 e7 mov %r12,%rdi
3d38: e8 00 00 00 00 callq 3d3d <nfs_atomic_lookup+0xdd>
3d3d: 31 c9 xor %ecx,%ecx
3d3f: eb b0 jmp 3cf1 <nfs_atomic_lookup+0x91>

static struct dentry *nfs_atomic_lookup(struct inode *dir, struct dentry *dentr
{
...
} else if (res != NULL)
dentry = res;
out:
return res;
no_open:
return nfs_lookup(dir, dentry, nd); <---
}
--
Daniel J Blueman


2010-01-25 18:45:57

by Trond Myklebust

[permalink] [raw]
Subject: Re: [2.6.32.3] potentially uninitialised field in nfs_atomic_lookup...

On Mon, 2010-01-25 at 17:10 +0000, Daniel J Blueman wrote:
> When booting with 2.6.32.3 x86-64 with a debug configuration including
> kmemcheck activated, I'm seeing bytes reported as uninitialised [1]
> (here with value 0x33).
>
> This is with automount and NFS4 [2] and reproduces consistently; it
> appears to not be structure padding.
>
> What additional information would help on this?
>
> Daniel
>
> --- [1]
>
> WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
> (ffff88016cc180c8)
>
> 07000000000000003333333333333333808d7e6d0188ffff988d7e6d0188ffff
>
> i i i i i i i i u u u u u u u u i i i i i i i i i i i i i i i i
>
>
>
> Modules linked in: nfs lockd nfs_acl auth_rpcgss netconsole configfs
> autofs4 sunrpc af_packet ipv6 msr binfmt_misc dm_mod nvram evdev
> psmouse rtc_cmos rtc_core rtc_lib e1000e piix pata_acpi
> ide_pci_generic ata_generic rng_core ext3 jbd mbcache uhci_hcd
> ohci_hcd ehci_hcd usbcore [last unloaded: microcode]
>
> [<ffffffffa0236d2e>] nfs_atomic_lookup+0xce/0x110 [nfs]
>
> [<ffffffff8113e13a>] do_lookup+0x1da/0x220
>
> [<ffffffff8113e5c0>] __link_path_walk+0x440/0x760
>
> [<ffffffff8113e937>] path_walk+0x57/0xb0
>
> [<ffffffff8113e9fa>] vfs_path_lookup+0x6a/0xe0
>
> [<ffffffffa023f370>] nfs_follow_remote_path+0x50/0x150 [nfs]
>
> [<ffffffffa023fe97>] nfs4_try_mount+0x77/0xd0 [nfs]
>
> [<ffffffffa024107b>] nfs4_get_sb+0x13b/0x320 [nfs]
>
> [<ffffffff81134e18>] vfs_kern_mount+0x58/0xe0
>
> [<ffffffff81134f0e>] do_kern_mount+0x4e/0x110
>
> [<ffffffff8114dd06>] do_mount+0x546/0x7c0
>
> [<ffffffff8114e00a>] sys_mount+0x8a/0xd0
>
> [<ffffffff8100be2b>] system_call_fastpath+0x16/0x1b
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
>
> --- [2]
>
> auto.direct /net/home autofs
> rw,relatime,fd=5,pgrp=4013,timeout=300,minproto=5,maxproto=5,direct 0
> 0
> filer:/home /net/home nfs4
> rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=65535,timeo=600,retrans=3,sec=sys,clientaddr=172.16.0.130,addr=172.16.0.110
> 0 0
>
> --- [3]
>
> /net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1044
> 3cf1: 48 8b 5d e8 mov -0x18(%rbp),%rbx
> 3cf5: 4c 8b 65 f0 mov -0x10(%rbp),%r12
> 3cf9: 48 89 c8 mov %rcx,%rax
> 3cfc: 4c 8b 6d f8 mov -0x8(%rbp),%r13
> 3d00: c9 leaveq
> 3d01: c3 retq
> /net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1022
> 3d02: 83 f8 ec cmp $0xffffffffffffffec,%eax
> 3d05: 74 19 je 3d20 <nfs_atomic_lookup+0xc0>
> 3d07: 83 f8 fe cmp $0xfffffffffffffffe,%eax
> 3d0a: 74 5e je 3d6a <nfs_atomic_lookup+0x10a>
> 3d0c: 83 f8 d8 cmp $0xffffffffffffffd8,%eax
> 3d0f: 90 nop
> 3d10: 75 df jne 3cf1 <nfs_atomic_lookup+0x91>
> /net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1031
> 3d12: f6 83 8a 00 00 00 02 testb $0x2,0x8a(%rbx)
> 3d19: 75 d6 jne 3cf1 <nfs_atomic_lookup+0x91>
> 3d1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> /net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1043
> 3d20: 48 89 da mov %rbx,%rdx
> 3d23: 4c 89 e6 mov %r12,%rsi
> 3d26: 4c 89 ef mov %r13,%rdi
> 3d29: e8 22 fd ff ff callq 3a50 <nfs_lookup>
> 3d2e: 48 89 c1 mov %rax,%rcx <----
> 3d31: eb be jmp 3cf1 <nfs_atomic_lookup+0x91>
> /net/cluster/daniel/kernel/linux-2.6.32.3/fs/nfs/dir.c:1014
> 3d33: 31 f6 xor %esi,%esi
> 3d35: 4c 89 e7 mov %r12,%rdi
> 3d38: e8 00 00 00 00 callq 3d3d <nfs_atomic_lookup+0xdd>
> 3d3d: 31 c9 xor %ecx,%ecx
> 3d3f: eb b0 jmp 3cf1 <nfs_atomic_lookup+0x91>
>
> static struct dentry *nfs_atomic_lookup(struct inode *dir, struct dentry *dentr
> {
> ...
> } else if (res != NULL)
> dentry = res;
> out:
> return res;
> no_open:
> return nfs_lookup(dir, dentry, nd); <---
> }

I'm not sure I understand. You're saying that kmemcheck is reporting the
nfs_lookup() return value as being uninitialised?

The only place I can see such a value coming from, would be from the
calls to NFS_PROTO(dir)->lookup(), nfs_fhget() and
d_materialise_unique(). Since the return values from those calls are
tested, why isn't kmemcheck pouncing on the uninitialised fields in
those tests?

Were you also running with stack overflow checking?

Cheers
Trond