Bug 22182 - usbmon: completed ISO packet content is not fully arriving with mmap
usbmon: completed ISO packet content is not fully arriving with mmap
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 normal
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-06 14:36 UTC by Márton Németh
Modified: 2011-03-30 23:37 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.36
Tree: Mainline
Regression: No


Attachments
example Wireshark capture (1.91 KB, application/cap)
2010-11-06 14:38 UTC, Márton Németh
Details
Parsed content of the capture file (17.98 KB, text/plain)
2010-11-06 14:40 UTC, Márton Németh
Details
2nd example Wireshark capture (1.59 KB, application/cap)
2010-11-06 15:12 UTC, Márton Németh
Details
Parsed content of the 2nd capture file (16.15 KB, text/plain)
2010-11-06 15:13 UTC, Márton Németh
Details
Suggested fix #2 (contra original) (1.97 KB, patch)
2010-12-01 01:47 UTC, Pete Zaitcev
Details | Diff

Description Márton Németh 2010-11-06 14:36:28 UTC
The ISO data in a completed URB is not necessarily begins at the first ISO block. When the URB is submitted then each ISO blcok is set to the maximal size.

In the attached example capture (which was created with Wireshark) we can see two captured packets: the first one is the submitted URB and the second one is the completed URB. The submitted URB has 24 ISO descriptor, 800 bytes each. This URB is captured all right.

The second packet contains the completed URB. In the user space we see that there are 1000 data bytes in this URB. This data is spread between ISO blocks 0...5 giving 155+160+185+174+156+170=1000. ISO desc 6...12 have zero length each. ISO desciptors 13..23 are not completed (-EXDEV). The problem is that the first 1000 bytes transfered from the kernel contains 800 bytes from the isodesc 0 out of 155 bytes are used. The next 800 bytes are not transfered completely, only the first 200 bytes out of 16 bytes are used. Then isodesc 2...5 are not transfered at all.

The reason might be that in drivers/usb/mon/mon_bin.c, in function mon_bin_event() the possible gaps are not taken into account together with memory mapped operation.
Comment 1 Márton Németh 2010-11-06 14:38:30 UTC
Created attachment 36312 [details]
example Wireshark capture
Comment 2 Márton Németh 2010-11-06 14:40:27 UTC
Created attachment 36322 [details]
Parsed content of the capture file
Comment 3 Márton Németh 2010-11-06 14:55:22 UTC
I could imagine different expected behaviours:

(a) the transfered size equals to 800+800+800+800+800+170=4170 bytes, so the iso desc 0...4 are fully transfered and the useful data from  isodesc 5 

(b) the transfered size equals to 800+800+800+800+800+800=4800 bytes, so the iso desc 0...5 are fully transfered

(c) the transfered size equals to maximum possible size always, in this case 24*800=19200 bytes
Comment 4 Márton Németh 2010-11-06 15:12:22 UTC
Created attachment 36362 [details]
2nd example Wireshark capture

In this second example we have an URB submitted with 24 ISO descritors, 800 bytes each.

The completed URB contains 242+101+177+156=767 data bytes. The ISO blocks 0...19 contains no data. The data is spread in ISO blocks 20..23.
Comment 5 Márton Németh 2010-11-06 15:13:24 UTC
Created attachment 36372 [details]
Parsed content of the 2nd capture file
Comment 6 Márton Németh 2010-11-14 16:00:39 UTC
Proposed patch sent, see http://lkml.org/lkml/2010/11/13/148 .
Comment 7 Pete Zaitcev 2010-12-01 01:47:02 UTC
Created attachment 38712 [details]
Suggested fix #2 (contra original)
Comment 8 Florian Mickler 2011-01-22 12:40:24 UTC
merged in .38-rc1: 
commit b17ea167c5fb50dcd5dce5b874a467f04eec886d
Author: Pete Zaitcev <zaitcev@redhat.com>
Date:   Tue Nov 16 21:51:19 2010 -0700

    usbmon: correct length for isochronous

Note You need to log in before you can comment on or make changes to this bug.