On Tue, 26 May 2009, David Brownell wrote: > On Thursday 21 May 2009, Alan Stern wrote: > > Dave: > > > > ehci_iso_stream->rescheduled and ->start seem never to get used. In > > fact I can't even tell what ->rescheduled is supposed to count, since > > it doesn't get incremented. Should they be removed? > > I guess so. Might be worth finding what removed setting ->rescheduled, > since I know that message used to appear sometimes (when rude things > happened). Hmm. I don't have records here going back before 2.6.10, and it wasn't being used back then either. > > The BUG_ON that's commented out of itd_patch() can actually be > > triggered if somebody submits an URB with a sufficiently discontiguous > > list of packet offsets. > > Discontiguous packet offsets sound kind of rude. :) Well maybe, but I can imagine situations where you might want to use them. For instance, you have allocated a buffer with room for 10 256-byte packets and you want to keep the layout always the same for simplicity, but it turns out that sometimes a few of the packets need to be shorter. Of course that's not an extreme case, and it wouldn't cause any problems. > > Without the BUG_ON, the result is memory > > corruption. There's a comment about the offsets being strictly > > increasing, but that's not enough to prevent the bug. > > What's that bug? The bug is that the driver will try to squeeze more than 6 pages into the data structure. :-) > > Neither > > requirement is documented, so what should we do about this? > > I'd have to dive into that code again ... ISTR "cross" would > be set on ITDs where a packet went from one page to the next, > the model being that the ITD would only ever use a contiguous > chunk of memory. There are hardware requirements on packet > layout in the ITDs, but I don't recall noticing any conflicts > between those and the software. The code allocates a new page entry whenever a packet crosses a page boundary (i.e., "cross" is set) _or_ a packet starts on a different page from where the previous one ended. With sufficiently bad offsets, both these things can happen with every packet. For example (assume the buffer is page-aligned): packet offset length ------ ------ ------ 0 0x0ff0 0x20 1 0x2ff0 0x20 2 0x4ff0 0x20 etc. Those three packets alone manage to touch six pages, since page boundaries occur at intervals of 0x1000. Add in another five packets to the iTD and you've got a problem... 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
