|
From: Tyler N. <tyl...@co...> - 2005-02-23 18:23:44
|
On Wed, 2005-02-23 at 08:20 -0800, Jeremy Fitzhardinge wrote: > Tyler Nielsen wrote: > > >I have been using valgrind on a program that makes use of USB ioctls. > >Up until now I've just been using hacks in the program to get around the > >uninitialized memory complaints. I finally sat down and started to put > >the code into valgrind so it understands the ioctls. I have been > >successful, and have a build of valgrind that handles all the ioctls I > >use correctly. However now I'm trying to get it into a state so that I > >can submit a patch for it, and there is one circumstance that I don't > >know how to deal with. Basically one ioctl affects the memory written > >to by the next ioctl. Attached is the patch needed for these ioctls to > >work. The question is, is this the correct way to handle this, or is > >there a better way. > > > No, this definitely isn't correct. Not threadsafe for one thing. What > is the URB pointer state associated with? The file descriptor? An > underlying device? > > A more general comment is that I'd really like to come up with a way of > dealing with ioctls which doesn't require adding more stuff into > vg_unsafe.h, and doesn't require duplicating structures into vki*.h. > J btw. It does look wrong to me, I just couldn't find the 'right' way. I assume that it is tied to the file descriptor, but I can't find any documentation that explicitly says that. There is a option to set a user pointer to some context (that is how you identify which urb completed). Perhaps a better way to do this would be to have valgrind modify this user pointer before the first ioctl, and undo the modification after the second ioctl. This should be 100% correct behavior, but would require either a malloc/free or some allocated space, and I didn't really see that happening anywhere in vg_syscalls.c. -- Tyler Nielsen <tyl...@co...> |