From: Douglas Gilbert <dougg@torque.net>
To: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: inquiry in scsi_scan.c
Date: Sat, 04 Jan 2003 13:14:40 +1100 [thread overview]
Message-ID: <3E164390.4040305@torque.net> (raw)
In-Reply-To: 20030103170404.D4315@one-eyed-alien.net
Matthew Dharm wrote:
> Actually, 5 isn't minimal... it's sub-minimal. That's an error in the
> INQUIRY data. The minimum (by spec) is 36 bytes.
>
> There should probably be a sanity check to never ask for INQUIRY less than
> 36 bytes. I thought there used to be such a thing....
Matt,
The scan code does a 36 byte INQUIRY first and then does
a second INQUIRY if the response indicates more (than 36
bytes) is available. In this case _less_ than 36 bytes
was supplied. So either the scsi scan code or usb-storage **
needs to make some pro forma vendor, model and rev strings.
We found previously that doing a longer INQUIRY (254
or 255 bytes) locked up some [arguably broken] usb devices.
Hence we switched to the twin INQUIRY strategy. Evidentally
FreeBSD does the same thing.
Throwing away such broken devices is not an option I guess.
What does that device look like under Windows?
** Assuming the usb device in question is using usb-storage,
shouldn't it make sure at least 36 (valid) bytes of response
data is supplied by an INQUIRY? Andrew Morton had to do this
(perhaps at a lower level in the usb stack) to make some device
he had play with the scsi subsystem.
Doug Gilbert
> On Sat, Jan 04, 2003 at 01:21:11AM +0100, Andries.Brouwer@cwi.nl wrote:
>
>>Got a new USB device and noticed some scsi silliness while playing with it.
>>
>>A bug in scsi_scan.c is
>>
>> sdev->inquiry = kmalloc(sdev->inquiry_len, GFP_ATOMIC);
>> memcpy(sdev->inquiry, inq_result, sdev->inquiry_len);
>> sdev->vendor = (char *) (sdev->inquiry + 8);
>> sdev->model = (char *) (sdev->inquiry + 16);
>> sdev->rev = (char *) (sdev->inquiry + 32);
>>
>>since it happens that inquiry_len is short (in my case it is 5)
>>and the vendor/model/rev pointers are wild.
>>Catting /proc/scsi/scsi now yields random garbage.
>>
>>I made a patch but hesitated between a small patch and a larger one.
>>Why do we have this malloced inquiry field? As far as I can see
>>nobody uses it. And the comment in scsi_add_lun() advises us
>>not to save the inquiry, precisely what we did until recently.
>>So, should this change from 2.5.11 be reverted?
>>
>>Andries
>>
>>
>>[My present scsi_scan.c differes quite a lot from a stock one.
>>Already fixed the scsi_check_id_size() some time ago.
next prev parent reply other threads:[~2003-01-04 2:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-04 0:21 inquiry in scsi_scan.c Andries.Brouwer
2003-01-04 1:04 ` Matthew Dharm
2003-01-04 2:14 ` Douglas Gilbert [this message]
2003-01-04 2:44 ` Patrick Mansfield
2003-01-05 0:45 ` Matthew Dharm
-- strict thread matches above, loose matches on Subject: below --
2003-01-04 3:07 Andries.Brouwer
2003-01-05 0:41 ` Matthew Dharm
2003-01-04 3:24 Andries.Brouwer
2003-01-05 13:07 Andries.Brouwer
2003-01-05 19:36 ` Luben Tuikov
2003-01-05 20:54 ` Zwane Mwaikambo
2003-01-05 20:54 ` Zwane Mwaikambo
2003-01-05 21:35 Andries.Brouwer
2003-01-05 22:05 ` Luben Tuikov
2003-01-05 21:42 Andries.Brouwer
2003-01-06 20:52 ` Patrick Mansfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E164390.4040305@torque.net \
--to=dougg@torque.net \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mdharm-kernel@one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.