On Tue, 2010-03-02 at 08:36 -0500, Martin K. Petersen wrote: > James, > > While I agree the original VPD code's double kmalloc() was a bit of a > wart at least it did the right thing because it allocated a suitably > sized buffer for page 0. > > My concern with the interface you introduced in e3deec09 is that for > devices that support a large number of VPD pages we won't be able to fit > the page list in the allocated buffer. And callers are likely to pick a > buffer size that makes sense for the VPD page they are interested in. > It's not a big deal in the block limits/block device characteristics > case because they are big enough. Actually, I don't really think that's a problem. The design is to weed out USB devices that have silly returns, either by not returning a correct page zero, or by only accepting VPDs to the few pages and crashing on ones they don't support. If we run off the end of the buffer because there are 32 or more pages, then it's reasonably safe to assume the device will respond correctly to a VPD inquiry. > But at the very minimum that interface should come with a big fat > warning in the comment section that describes that the page list must > also be able to fit. But it doesn't have to ... if we correctly return more pages than will fit in the buffer, it will proceed to do the requested page VPD inquiry. James -- 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
