linux-kernel - Re: [PATCH v3] scsi: report 'INQUIRY result too short' once per host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <561CA1C6.2010207@suse.de>
Date:	Tue, 13 Oct 2015 08:16:38 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>
CC:	"James E.J. Bottomley" <JBottomley@...n.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Long Li <longli@...rosoft.com>,
	Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH v3] scsi: report 'INQUIRY result too short' once per host

On 10/12/2015 05:16 PM, Vitaly Kuznetsov wrote:
> Hannes Reinecke <hare@...e.de> writes:
> 
>> On 10/08/2015 06:54 PM, Vitaly Kuznetsov wrote:
>>> Some host adapters (e.g. Hyper-V storvsc) are known for not respecting the
>>> SPC-2/3/4 requirement for 'INQUIRY data (see table ...) shall contain at
>>> least 36 bytes'. As a result we get tons on 'scsi 0:7:1:1: scsi scan:
>>> INQUIRY result too short (5), using 36' messages on console. This can be
>>> problematic for slow consoles. Introduce short_inquiry flag in struct
>>> Scsi_Host to print the message once per host.
>>>
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>>> ---
>>> Changes since v2:
>>> - This is a successor of previously sent (and still not merged) "scsi:
>>>   introduce short_inquiry flag for broken host adapters" patch. I'm not
>>>   particularly sure which solution is better but I'm leaning towards this
>>>   one as it doesn't require changes to adapter drivers.
>>> ---
>>>  drivers/scsi/scsi_scan.c | 9 ++++++---
>>>  include/scsi/scsi_host.h | 3 +++
>>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
>>> index f9f3f82..cd347e4 100644
>>> --- a/drivers/scsi/scsi_scan.c
>>> +++ b/drivers/scsi/scsi_scan.c
>>> @@ -701,9 +701,12 @@ static int scsi_probe_lun(struct scsi_device *sdev, unsigned char *inq_result,
>>>  	 * strings.
>>>  	 */
>>>  	if (sdev->inquiry_len < 36) {
>>> -		sdev_printk(KERN_INFO, sdev,
>>> -			    "scsi scan: INQUIRY result too short (%d),"
>>> -			    " using 36\n", sdev->inquiry_len);
>>> +		if (!sdev->host->short_inquiry) {
>>> +			shost_printk(KERN_INFO, sdev->host,
>>> +				    "scsi scan: INQUIRY result too short (%d),"
>>> +				    " using 36\n", sdev->inquiry_len);
>>> +			sdev->host->short_inquiry = 1;
>>> +		}
>>>  		sdev->inquiry_len = 36;
>>>  	}
>>>  
>> At least you need to check if you've received any valid data here;
>> 'INQUIRY result too short' is also a common error if the interrupt
>> is hosed when trying to access the device.
>> So please check for 'inquiry_len > 4' before setting 'short_inquiry'.
> 
> Currently we proceed even with a shorter reply... Should we abort the
> scan (and return -EOI?) in case we got inquiry_len <= 4?
> 
Yes please. We need to ensure that we actually received some data,
and not running into an error scenario here.
So we need to read at least five bytes of data, as byte 4 carries
the response length. If we read less than that we have no way of
figuring out if the response data is even remotely sane.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@...e.de			               +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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/