Re: [Valgrind-users] compat_ioctl cmd does not match even if it shows same value

[Manomugdha B. <man...@ke...>]

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 <jr...@bi...> 
Sent: Saturday, August 15, 2020 11:28 PM
To: val...@li...
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
Val...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/valgrind-users__;!!I5pVk4LIGAfnvw!w9ZQebKExIzQOBnXRp0AgAnSuApBAKyRQwK8-da-j4Y9NjzgGTYvJNpMt7LSIX7caCZHaZDi$