On 08/04/2017 06:38 PM, Bart Van Assche wrote:
> On Fri, 2017-08-04 at 18:28 +0200, Hannes Reinecke wrote:
>> Well, maybe; however, the current logic fails to match the entry
>>
>> {"HITACHI", "OPEN-", "*", BLIST_REPORTLUN2},
>>
>> against the 'real' name, which is "HITACHI" "OPEN-V".
>> And for some reason we have far more customer using Hitachi arrays than
>> using scanner of dubious provenance with no Vendor (which is the real
>> bug if you ask me...)
>
> Hello Hannes,
>
> So for some entries in the table a prefix match should be performed (e.g. the
> model string for the Hitachi entry) but for other entries (e.g. the scanner
> entry) an exact match should be performed on the vendor name? If so, how about
> one of the following two approaches:
> * Adding ".*" at the end of the entries in the table for which a prefix match
> is sufficient and to change scsi_dev_info_list_find() such that it performs
> a regex match instead of an exact match or a prefix match.
> * Performing an exact match on the vendor name and a prefix match on the model
> name.
>
Doesn't work, as we have no idea which strings should be treated as
exact match and for which a partial match is applicable.
The solution is actually far simpler:
- Always assume partial match
- Check the min string length for vendor and model
- Do not attempt to match if the min length is zero
These rules drastically simplify the code.
Additionally I've done patches to export the blacklist value to sysfs,
_and_ modified scsi_debug to allow us to pass in the vendor and model
string.
With these modifications we can easily write blocktests to cover the
various corner cases, and have proper regression tests in case someone
needs to twiddle with that again.
Patchset to follow.
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)
