On Mon, Jan 9, 2012 at 4:15 PM, Andy Grover <agrover@xxxxxxxxxx> wrote: > Most commands define a 16 bit allocation length field, so we need to > handle up to 65K. I don't think that's true, eg REPORT LUNS has a 32-bit allocation length, same for REPORT TARGET PORT GROUPS, probably others that we handle. And actually we probably need more checking of the allocation length before we go ahead and allocate the memory, if someone sends a REPORT LUNS with a 2GB allocation length we'll go ahead and try to allocate 2GB. > To remove that test, we need all 19 functions that use > transport_kmap_first_data_page() modified to handle multiple pages. I > still think this is better than going back to linear buffers. nab why > don't you let me take this one, hopefully it won't be too bad, and I'll > try to have a patch ready for review by Wednesday. Maybe the simplest thing to do is use vmap() on the whole buffer? The unmap needs a global TLB shootdown but it's not like these control CDBs are on a fastpath anyway... But OTOH it would be good if we allocate the memory on demand to handle the 2GB allocation length case I mentioned above, so we handle the case where an initiator sends us an allocation length much longer than we actually need. The flip side of that is that we also want to handle the case where the initiator sends an allocation length shorter than what we need to return the data. What we're supposed to do in that case is act like we generated the whole response but truncate the actual data we return. You definitely don't have to solve all those problems at once but we should definitely keep them in mind so we don't make them harder to solve in the long run. - R. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
