> But most of what you're doing in that patch set doesn't work. The whole > reason for separating the sense buffer from the scsi command is the DMA > problem of cache line interference caused by doing DMA to an area > embedded in a structure that has host accessed variables in it. With > what you're doing embedding the sense buffer in the internal control > areas, you're re-introducing that bug. Hmm if that was really a problem it would be trivial to pad it to cache lines. On what card did you see that? Also I don't think the current sense pool is cache line aligned anyways, so there is already potentially this problem with other data. Anyways from my audit of the ISA drivers I found that very few (only one or two) do actually DMA to the sense buffer anyways. Most just memcpy it from somewhere else. DMA is really the oddball case for the ISA drivers (that is why with the old unchecked_isa_dma there was a lot of unnecessary work for this) > Additionally, it really doesn't make sense for every driver to do a roll > your own allocator. It is only a very small number of drivers. And GFP_DMA in the mid layer has many problems. > It makes far more sense for them to be allocated > centrally (and correctly) so there's only one place it needs fixing if > there's yet another problem discovered. The main issue with GFP_DMA in the mid layer (that is why i started my patchkit originally) was that GFP_DMA does not work very well. First it means different things on different architectures, then on x86 if you go outside old legacy ISA drivers the drivers with limited DMA masks typically don't need 24bit but something larger. I think for such special situations (again we're talking only about a relatively small number of drivers) it is much better to do the mapping and allocation in the low level driver who knows far better what it really needs. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html