On Wed, 28 Oct 2009, Pete Zaitcev wrote:
> On Wed, 28 Oct 2009 09:48:33 -0700, <gregkh@xxxxxxx> wrote:
>
> > -static void mon_buff_area_shrink(struct mon_reader_bin *rp, unsigned int size)
> > +static void mon_buff_area_shrink(struct mon_reader_bin *rp, unsigned int num,
> > + unsigned int oldsize)
>
> > - mon_buff_area_shrink(rp, length);
> > + mon_buff_area_shrink(rp, length,
> > + length + PKT_SIZE + lendesc);
>
> This looks completely wrong, because by the time we're shrinking
> the area (rp), it must have been set up already, with the data
> tacked at the end. Anything else means that the integrity of the
> circular buffer is lost! Therefore, it should be possible to
> shrink the rp using the data length as a guide, regardless of
> ISO descriptors.
Perhaps my description of the changes wasn't explicit enough.
-static void mon_buff_area_shrink(struct mon_reader_bin *rp, unsigned int size)
+static void mon_buff_area_shrink(struct mon_reader_bin *rp, unsigned int num,
+ unsigned int oldsize)
In the original function, "size" is the number of bytes you want to
remove from the end of rp's area, right? In the new version, "num" is
the amount to be removed and "oldsize" is the current size of the area.
This explains the other change:
- mon_buff_area_shrink(rp, length);
+ mon_buff_area_shrink(rp, length,
+ length + PKT_SIZE + lendesc);
This code runs when none of the URB's data could be copied. "length"
is the size of that data, which we want to remove from the end of rp's
area. The area was originally allocated using length + PKT_SIZE +
lendesc as the total size, to hold the usbmon header info, the isoc
descriptors, and the URB data. The code for the initial allocation of
rp is a little earlier in mon_bin_event():
if (rp->mmap_active) {
offset = mon_buff_area_alloc_contiguous(rp,
length + PKT_SIZE + lendesc);
} else {
offset = mon_buff_area_alloc(rp, length + PKT_SIZE + lendesc);
}
Does this help clarify things?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
