[LTP] Avoid syscall param ioctl(generic) points to uninitialised byte(s)

[Cyril Hrubis]

Hi!
> > > diff --git a/testcases/kernel/syscalls/userfaultfd/userfaultfd01.c b/testcases/kernel/syscalls/userfaultfd/userfaultfd01.c
> > > index 7368d3863..d24766e7c 100644
> > > --- a/testcases/kernel/syscalls/userfaultfd/userfaultfd01.c
> > > +++ b/testcases/kernel/syscalls/userfaultfd/userfaultfd01.c
> > > @@ -92,8 +92,8 @@ static void *handle_thread(void)
> > >  static void run(unsigned int i)
> > >  {
> > >  	pthread_t thr;
> > > -	struct uffdio_api uffdio_api = {};
> > > -	struct uffdio_register uffdio_register;
> > > +	struct uffdio_api uffdio_api = {0, };
> > > +	struct uffdio_register uffdio_register = {0, };
> > 
> > Given that we were using = {}; in the code before can we keep using that
> > and for all instances?
> 
> I saw both initializers in the LTP source, see `$ grep -rIn  '= {};'` and
> `$ grep -rIn  '= { 0, };'`.  The latter one is compliant with older standards.
> But to keep the coding style within this file, I've updated the initializer.
> 
> > Also I assume the problem is the ioctls field in the uffdio_api
> > structure that is not initialized beacuse is supposed to be set by
> > kernel before returning into userspace. Should valgrind warn about such
> > cases?
> 
> You are right that zeroing just this uffdio_register.ioctls = 0; is suffi-
> cient to to avoid the valgrind complaint.  Zeroing whole the struct seems
> syntactically more concise and also correct.

That's not what I was trying to point out. Some fields of structures
passed to ioctls are output-only. The question is if valgrind should
warn if we do not set output only field in such structure?

-- 
Cyril Hrubis
chrubis@suse.cz