Hi John,
Valgrind version: valgrind-3.14.0
compat_ioctl prototype:
/* File operations core */
struct file_operations mgr_fops =
{
owner:
THIS_MODULE,
open:
mgr_open_common,
FILE_OPS_IOCTL(mgr_ioctl_common),
#ifdef CONFIG_COMPAT
compat_ioctl:
mgr_compat_ioctl,
#endif
poll:
mgr_poll_common,
release:
mgr_close_common
};
long mgr_compat_ioctl(struct file *pFile, unsigned int cmd, unsigned long arg)
{
int err = -EFAULT;
//unsigned int openLink = kIoctlOpenEthernetLink;
unsigned int openLink = 3222829167;
printk("cmd 0x%x/%u, openLink 0x%x/%u\n", cmd, cmd, openLink, openLink);
if (openLink == cmd) {
printk("match\n");
} else {
printk("no match: cmd 0x%x/%u, openLink 0x%x/%u\n", cmd, cmd, openLink,
openLink);
}
}
Output is:
[409204.415924/1] cmd 0xc018786f/3222829167, openLink 0xc018786f/3222829167
[409204.415933/1] no match: cmd 0xc018786f/3222829167, openLink
0xc018786f/3222829167
Note1: it fails at MSB. If i do memcmp instead of "if" then it works.
Note2: this is happening only under valgrind. When I run it without valgrind
then it works fine.
Note3: this is a kernel module and ioctl is called from user space application.
Regards,
Mano
-----Original Message-----
From: John Reiser <jrei...@bitwagon.com>
Sent: Saturday, August 15, 2020 11:28 PM
To: valgrind-users@lists.sourceforge.net
Subject: Re: [Valgrind-users] compat_ioctl cmd does not match even if it shows
same value
[EXTERNAL]
> 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.
--
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/valgrind-users__;!!I5pVk4LIGAfnvw!w9ZQebKExIzQOBnXRp0AgAnSuApBAKyRQwK8-da-j4Y9NjzgGTYvJNpMt7LSIX7caCZHaZDi$
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
