Bug 101500

Summary: strace confuses MTIOCTOP for SNDCTL_MIDI_MPUMODE
Product: [Retired] Red Hat Linux Reporter: Pete Zaitcev <zaitcev>
Component: straceAssignee: Roland McGrath <roland>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-09-23 23:36:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Pete Zaitcev 2003-08-01 21:20:07 UTC
Running strace of "mt stoptions" produces this:

open("/dev/nst0", O_RDONLY|O_NONBLOCK)  = 3
ioctl(3, SNDCTL_MIDI_MPUMODE, 0xbfffefc0) = 0
close(3)                                = 0

Or, with "-e raw=ioctl":

open("/dev/nst0", O_RDONLY|O_NONBLOCK)  = 3
ioctl(0x3, 0x40086d01, 0xbfffe0c0)      = 0
close(3)                                = 0

#define MTIOCTOP        _IOW('m', 1, struct mtop)       /* do a mag tape op */
#define SNDCTL_MIDI_MPUMODE           _SIOWR('m', 1, int)

Upper bits in the ioctl command cannot be the same: sizes are different.

Not a big problem as long as I can see the raw number, but FYI,
in case you want to overhaul how strace matches ioctl numbers.

Comment 1 Pete Zaitcev 2003-08-01 21:22:29 UTC
[zaitcev@niphredil zaitcev]$ rpm -q strace
strace-4.4.95-2


Comment 2 Roland McGrath 2003-09-23 23:36:23 UTC
AFAICT this has been broken upstream since 4.4 because of wrong assumptions in
the revamp of ioctl handling done between 4.3 and 4.4.  The situation is dicey,
because there seems to be no law or convention that prevents multiple unrelated
ioctl codes being defined for different devices using the same value.  It so
happens that these two do not actually collide because of the data sizes, but
the overloading of the 'm' code letter for SNDCTL_* and MTIO_* codes means that
new additions could easily collide.  If that were to happen, strace would have
no way to know which one you had in mind.

I don't think I will fix this upstream before the strace-4.5 release,
it will have to go on the list of known bugs.