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

[Martin Cermak]

On  Thu  2026-04-16  12:07 , Cyril Hrubis wrote:
> 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?

You are very right.  Curent version of valgrind doesn't recognize
UFFDIO_REGISTER, and treats this ioctl as unknown ioctl via
ML_(PRE_unknown_ioctl)(tid, ARG2, ARG3);  Good point, thanks!

Martin