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

2020-08-15 Thread Manomugdha Biswas via Valgrind-users 
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  
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

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

2020-08-15 Thread John Reiser 

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://lists.sourceforge.net/lists/listinfo/valgrind-users

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

2020-08-15 Thread Manomugdha Biswas via Valgrind-users 
Hi,
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

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 variable to which this cmd is to be matched has exactly same 
value of 0xc018786f (printk shows same value). But still if check fails.

Sample code is like this:
int mgr_ioctl_common (struct inode *pInode, struct file *pFile,
 unsigned int cmd, unsigned long arg)
{
int err = -EFAULT;
int minor;
void  *pUserStruct = (void *)arg;
SkixpppMgrDevDesc *pDev = NULL;
tKHandle retHandle;

unsigned int openLink = 3222829167;
   if (openLink == cmd) { //printk shows value of cmd is 3222829167
  printk("matches\n");
   } else {
  printk("no matche\n");
  }
}
Why this if check fails here?

Regards,
Mano


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

2020-08-15 Thread Manomugdha Biswas via Valgrind-users 
(openLink - cmd) shows zero still if check fails.
Note: this is happening only under valgrind!

Regards,
Mano, IxNetwork
[Keysight-signature-block-5]

From: Manomugdha Biswas
Sent: Saturday, August 15, 2020 6:38 PM
To: valgrind-users@lists.sourceforge.net
Subject: compat_ioctl cmd does not match even if it shows same value

Hi,
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

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 variable to which this cmd is to be matched has exactly same 
value of 0xc018786f (printk shows same value). But still if check fails.

Sample code is like this:
int mgr_ioctl_common (struct inode *pInode, struct file *pFile,
 unsigned int cmd, unsigned long arg)
{
int err = -EFAULT;
int minor;
void  *pUserStruct = (void *)arg;
SkixpppMgrDevDesc *pDev = NULL;
tKHandle retHandle;

unsigned int openLink = 3222829167;
   if (openLink == cmd) { //printk shows value of cmd is 3222829167
  printk("matches\n");
   } else {
  printk("no matche\n");
  }
}
Why this if check fails here?

Regards,
Mano


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Use of valgrind with microthreading

2020-08-15 Thread Philippe Waroquiers 
On Fri, 2020-08-14 at 19:16 +0200, Mark Wielaard wrote:
> Hi Shachar,
> 
> On Fri, Aug 14, 2020 at 06:35:14PM +0300, Shachar Shemesh wrote:
> > I am writing my own C++ microthreading library. At the very first switch, I
> > get the following message from Valgrind:
> > 
> > ==15122== Warning: client switching stacks?  SP change: 0x1ffeffe788 -->
> > 0x75d0f80
> > ==15122==  to suppress, use: --max-stackframe=137298630664 or
> > greater
> > 
> > 
> > I understand that valgrind needs to know where the stack starts and ends. I
> > am wondering whether is any way I can tell it that information. Since I'm
> > writing the library, what I was thinking was compiling the library with a
> > special flag saying "you're running with valgrind", and then have my library
> > call a valgrind function that says "This is the new stack range, this is the
> > old one".
> >  
> > Is there such a thing? If so, how do I interface with it?
> 
> Yes, there is such a thing. The valgrind client request mechanism:
> https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
> 
> It does have various VALGRIND_STACK_* macros to signal use of user
> threads/stacks. But note that the documentations says:
> Warning: Unfortunately, this client request is unreliable and best avoided.
> Unfortunately I don't know why that is, or what alternative mechanisms there 
> are.

I also do not know what the 'unreliable' doc warning points at.
Searching in bugzilla, there are a few bugs that are related to such STACK 
requests:
Bug 202463 - VALGRIND_STACK_{REGISTER,DEREGISTER,CHANGE} are unreliable 
Bug 133154 - crash when using client requests to register/deregister stack

However, some years ago, I did various improvements to the stack handling code
in order to better support running valgrind under valgrind: the inner valgrind 
is
using such client requests to inform the outer valgrind about the inner stacks.

So, IMO, these requests should (could?) work reasonably well.

Philippe

 




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users