<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt.git/drivers/usb/mon/mon_dma.c, branch 2010.2</title>
<subtitle>The LITMUS^RT kernel.</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/'/>
<entry>
<title>USB: usbmon: end ugly tricks with DMA peeking</title>
<updated>2009-09-23T13:46:19+00:00</updated>
<author>
<name>Pete Zaitcev</name>
<email>zaitcev@redhat.com</email>
</author>
<published>2009-06-11T14:53:20+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=4e9e92003529e5c7bb11281f7c2c9b3fe8858403'/>
<id>4e9e92003529e5c7bb11281f7c2c9b3fe8858403</id>
<content type='text'>
This patch fixes crashes when usbmon attempts to access GART aperture.
The old code attempted to take a bus address and convert it into a
virtual address, which clearly was impossible on systems with actual
IOMMUs. Let us not persist in this foolishness, and use transfer_buffer
in all cases instead.

I think downsides are negligible. The ones I see are:
 - A driver may pass an address of one buffer down as transfer_buffer,
   and entirely different entity mapped for DMA, resulting in misleading
   output of usbmon. Note, however, that PIO based controllers would
   do transfer the same data that usbmon sees here.
 - Out of tree drivers may crash usbmon if they store garbage in
   transfer_buffer. I inspected the in-tree drivers, and clarified
   the documentation in comments.
 - Drivers that use get_user_pages will not be possible to monitor.
   I only found one driver with this problem (drivers/staging/rspiusb).
 - Same happens with with usb_storage transferring from highmem, but
   it works fine on 64-bit systems, so I think it's not a concern.
   At least we don't crash anymore.

Why didn't we do this in 2.6.10? That's because back in those days
it was popular not to fill in transfer_buffer, so almost all
traffic would be invisible (e.g. all of HID was like that).
But now, the tree is almost 100% PIO friendly, so we can do the
right thing at last.

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes crashes when usbmon attempts to access GART aperture.
The old code attempted to take a bus address and convert it into a
virtual address, which clearly was impossible on systems with actual
IOMMUs. Let us not persist in this foolishness, and use transfer_buffer
in all cases instead.

I think downsides are negligible. The ones I see are:
 - A driver may pass an address of one buffer down as transfer_buffer,
   and entirely different entity mapped for DMA, resulting in misleading
   output of usbmon. Note, however, that PIO based controllers would
   do transfer the same data that usbmon sees here.
 - Out of tree drivers may crash usbmon if they store garbage in
   transfer_buffer. I inspected the in-tree drivers, and clarified
   the documentation in comments.
 - Drivers that use get_user_pages will not be possible to monitor.
   I only found one driver with this problem (drivers/staging/rspiusb).
 - Same happens with with usb_storage transferring from highmem, but
   it works fine on 64-bit systems, so I think it's not a concern.
   At least we don't crash anymore.

Why didn't we do this in 2.6.10? That's because back in those days
it was popular not to fill in transfer_buffer, so almost all
traffic would be invisible (e.g. all of HID was like that).
But now, the tree is almost 100% PIO friendly, so we can do the
right thing at last.

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: add binary API to usbmon</title>
<updated>2007-02-07T23:44:34+00:00</updated>
<author>
<name>Pete Zaitcev</name>
<email>zaitcev@redhat.com</email>
</author>
<published>2006-12-31T06:43:10+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=6f23ee1fefdc1f80bd8a3ab04a1c41ab2dec14c9'/>
<id>6f23ee1fefdc1f80bd8a3ab04a1c41ab2dec14c9</id>
<content type='text'>
This patch adds a new, "binary" API in addition to the old, text API usbmon
had before. The new API allows for less CPU use, and it allows to capture
all data from a packet where old API only captured 32 bytes at most. There
are some limitations and conditions to this, e.g. in case someone constructs
a URB with 1GB of data, it's not likely to be captured, because even the
huge buffers of the new reader are finite. Nonetheless, I expect this new
capability to capture all data for all real life scenarios.

The downside is, a special user mode application is required where cat(1)
worked before. I have sample code at http://people.redhat.com/zaitcev/linux/
and Paolo Abeni is working on patching libpcap.

This patch was initially written by Paolo and later I tweaked it, and
we had a little back-and-forth. So this is a jointly authored patch, but
I am submitting this I am responsible for the bugs.

Signed-off-by: Paolo Abeni &lt;paolo.abeni@email.it&gt;
Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds a new, "binary" API in addition to the old, text API usbmon
had before. The new API allows for less CPU use, and it allows to capture
all data from a packet where old API only captured 32 bytes at most. There
are some limitations and conditions to this, e.g. in case someone constructs
a URB with 1GB of data, it's not likely to be captured, because even the
huge buffers of the new reader are finite. Nonetheless, I expect this new
capability to capture all data for all real life scenarios.

The downside is, a special user mode application is required where cat(1)
worked before. I have sample code at http://people.redhat.com/zaitcev/linux/
and Paolo Abeni is working on patching libpcap.

This patch was initially written by Paolo and later I tweaked it, and
we had a little back-and-forth. So this is a jointly authored patch, but
I am submitting this I am responsible for the bugs.

Signed-off-by: Paolo Abeni &lt;paolo.abeni@email.it&gt;
Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] USB: update usbmon, fix glued lines</title>
<updated>2006-06-21T22:04:17+00:00</updated>
<author>
<name>Pete Zaitcev</name>
<email>zaitcev@redhat.com</email>
</author>
<published>2006-06-10T03:10:10+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=5b1c674d223eef6c6494be8be91e9e3a3054817e'/>
<id>5b1c674d223eef6c6494be8be91e9e3a3054817e</id>
<content type='text'>
This update contains one bug fix: some lines can come out truncated,
because of the safety cutoff. This happened because I forgot to update
the size when status packets began to be printed.

The rest is:
 - Comments updates
 - Allow snooping with pkmap on x86_64, which is cache-coherent
 - Enlarge event buffers (certainly we can have a couple of pages)
 - Add event counter

First touch upon usbmon for 2.6.18.

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This update contains one bug fix: some lines can come out truncated,
because of the safety cutoff. This happened because I forgot to update
the size when status packets began to be printed.

The rest is:
 - Comments updates
 - Allow snooping with pkmap on x86_64, which is cache-coherent
 - Enlarge event buffers (certainly we can have a couple of pages)
 - Add event counter

First touch upon usbmon for 2.6.18.

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] usbmon in 2.6.13: peeking into DMA areas</title>
<updated>2005-09-08T23:28:36+00:00</updated>
<author>
<name>Pete Zaitcev</name>
<email>zaitcev@redhat.com</email>
</author>
<published>2005-08-15T23:53:57+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=0256839619d9b1e933cafc83e7f0deaad4216465'/>
<id>0256839619d9b1e933cafc83e7f0deaad4216465</id>
<content type='text'>
This code looks at urb-&gt;transfer_dma, maps the page and takes the data.
I am looking for volunteers to contribute architectures other than i386
or to develop an architecure-neutral API for it (or point me that it
was done already).

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This code looks at urb-&gt;transfer_dma, maps the page and takes the data.
I am looking for volunteers to contribute architectures other than i386
or to develop an architecure-neutral API for it (or point me that it
was done already).

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
