On 12/22/2017 06:14 PM, James Bottomley wrote: > On Thu, 2017-12-21 at 12:22 +0100, Hannes Reinecke wrote: >> Some storage arrays have an incorrect SES implementation which will >> always return the allocation length of the CDB instead of the true >> length of the requested page. > > That's a pretty gross standards violation, is this common? When the > buffer is > than the data to return, does it get set then? Because if > not, we're going to be processing bogus data and no module parameter > can fix this because the returned length depends on the number of > elements in the enclosure making this parameter really unsafe unless > you get it exactly right. > It's actually the first time I've observed that; the vendor is already alerted. But yes, if the buffer is larger than the page the correct page size is set, so we won't be suffering from the above issue. >> With this patch one can modify the initial allocation size to >> get the full output of those arrays. > > This really doesn't look like the right way to do it. Shouldn't we > rather have a blacklist for these devices and simply do a page for each > allocation for them (assuming they return the correct length when over > subscribed). > I really doubt it's worth it. It's just a single array line with a particular firmware revision from what I've seen. The one problem we're continually running into is that the blacklist flags are essentially used up, so I'd be rather careful with adding some not-that-common scenarios to it. I would love to have the blacklist size increased, though; I do have a few other issues which would rather benefit from being handled by a blacklist flag ... Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)