On 4 September 2017 at 16:22, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Sep 04, 2017 at 11:11:04PM +0900, Tetsuo Handa wrote:
>> at __d_alloc() which leaves a room for some of d_iname[] bytes uninitialized?
>> So, I think either pad explicitly at __f_alloc() or use dentry->d_name.len + 1 is needed.
>
> It's the same situation as with
> struct foo {char s[10];int v;} *p, *q;
> p = malloc(sizeof struct foo);
> strcpy(p->s, "foo");
> p->v = 69;
> ...
> q = malloc(sizeof struct foo);
> memcpy(q, p, sizeof(struct foo));
>
> Sure, bytes after NUL are uninitialized, but that NUL is there
> in both copies. FWIW, kmemcheck could simply copy the information
> about source to that about destination - in the example above
> we'd end up with "q->v initialized, along with the first 4 bytes of
> q->s", which matches the reality. BTW, how do you handle struct
> assignments?
kmemcheck knows how to memcpy() the shadow memory state between two
slab-allocated objects, but it doesn't track memory state for the
stack so if you're copying partially uninitialised object to the stack
(which I'm guessing is the case here?) then it will produce the
warning Tetsuo Handa saw.
BTW as soon as msan/kmsan support for the kernel [1] is merged I am
planning to nuke kmemcheck from the kernel. msan/kmsan should handle
it properly.
[1]: https://github.com/google/kmsan
Vegard
