Possible bug in usb storage (2.6.11 kernel)

[Jim Ramsay]

I think I have found a possible bug:

In usb/storage/transport.c, the routine usb_stor_Bulk_transport (and
perhaps other releated routines as well) has the following in the
"DATA STAGE" (around line 1020 in my file):

result = usb_stor_bulk_transfer_sg(us, pipe,
                                        srb->request_buffer, transfer_length,
                                        srb->use_sg, &srb->resid);

This looks fine, except that there is no guarantee that
srb->request_buffer is page-aligned or cache-aligned, as is required
according to Documentation/DMA-API.txt

In fact, on my MIPS platform, I sometimes get odd hangs and panics
because the later call to "dma_map_single" on this buffer causes a
cache invalidation, and since this memory is not necessarily
cache-aligned, sometimes too much cache is invalidated, which causes
interesting (and annoying) memory corruptions.  Usually I've seen it
change the 'request' pointer in us->current_urb to something slightly
different, or zero, depending on the system's mood, but I'm sure there
are other possible ugly side-effects of this.

The solution, as suggested by Documentation/DMA-API.txt is to ensure
that all buffers passed into dma_map_single are always cache-aligned
(or at least page-aligned).

I would suggest this should be fixed by using a new buffer allocated
by the usb storage layer and then copying the result back into the
srb->request_buffer.

I suppose the scsi code could be changed to guarantee that
srb->request_buffer is page-aligned or cache-aligned, but that seems
like the wrong solution for this bug.

Questions?  Comments?  Is this the right way to fix it?

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/