Re: compat_ioctl cmd does not match even if it shows same value

> I have a 32 bit application (user space) which communicate with a kernel module through compat_ioctl(). My system is
> 
> # uname -a
> 
> Linux chassis1-board1-port5 3.10 #1 SMP Fri Apr 24 02:31:48 PDT 2020 mips64 GNU/Linux

Which version of valgrind?

The source code of valgrind:
     commit 24b247aec5397cad5f6cfcf885f118e90fea8735 (HEAD -> master, origin/master, origin/HEAD)
     Date:   Sat Aug 15 16:54:14 2020 +0200
does not contain the string 'compat_ioctl' anywhere, so you must show us the prototype
and the environment (32-bit or 64-bit) for compat_ioctl.

> Ioctl function is following:
> 
> long mgr_compat_ioctl(struct file *pFile, unsigned int cmd, unsigned long arg)
> 
> inside this function definition, I am getting correct cmd value e.g. 0xc018786f.

The fact that you write '0xc018786f' here, but '3222829167' in the code,
shows that you are not sufficiently paranoid.  First, if the bit pattern is important
then you should write hex.  If you insist on decimal, then you should write '3222829167u'
to remind yourself and the compiler that the value is unsigned; otherwise because
3222829167 exceeds INT_MAX then a compiler is allowed to interpret it as -1072138129
(or ANY VALUE WHATSOEVER!!!)
Then, it is very likely that your problem lies in a mismatch of width (64-bit vs 32-bit)
and/or signedness at one or more interfaces (subroutine call or system call).
You say "printk shows same value" but you did not say what format conversion
you specified to printk, therefore no one can determine what the actual value is.
This is likely to be important, because printk is implemented using "..." varargs,
and on most 64-bit machines that means that most scalar actual arguments are promoted
to 64-bit width upon the transition into the varargs mechanism, and it is UNSPECIFIED
whether the conversion from 32-bit to 64-bit is sign-extended or zero-extended.
That makes it extremely important that each varargs access uses the desired width
and signedness.

Due to the possibility of bugs, the only way to be sure of what is happening
is to look at the assembly-language code, and examine registers and values
while single-stepping actual execution.

--