linux-kernel - Re: [PATCH, RFC] usbmon: correct computing of the ISO packets with mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Nov 2010 10:01:54 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Pete Zaitcev <zaitcev@...hat.com>
cc:	Németh Márton <nm127@...email.hu>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	<linux-usb@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFC] usbmon: correct computing of the ISO packets with
 mmap

On Sun, 14 Nov 2010, Pete Zaitcev wrote:

> > > +	while (ndesc-- != 0) {
> > > +		if (fp->status == 0 && fp->actual_length != 0) {
> > 
> > I'd leave out the fp->status == 0 test.  It's not relevant; a buffer 
> > can contain valid data even if the final status isn't 0.
> 
> That's a good point, however is actual_length filled in such case?
> I thought it was either one or the other.

No, it's possible to have both.  This is less likely with isochronous 
than with the other transfer types, but it can happen.  For example, 
consider a high-bandwidth high-speed transfer where 3072 bytes are 
received in three packets during a single microframe.  You might 
receive two of the three packets, giving actual_length = 2048, and then 
not receive the third, giving status = -EPROTO.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/