From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: inquiry in scsi_scan.c
Date: Fri, 3 Jan 2003 17:04:04 -0800 [thread overview]
Message-ID: <20030103170404.D4315@one-eyed-alien.net> (raw)
In-Reply-To: <UTC200301040021.h040LB128544.aeb@smtp.cwi.nl>; from Andries.Brouwer@cwi.nl on Sat, Jan 04, 2003 at 01:21:11AM +0100
[-- Attachment #1: Type: text/plain, Size: 5919 bytes --]
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
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.
> Below some diff fragments from today.]
>
> +/*
> + * Do an INQUIRY with given length (minimum 5, maximum 255).
> + * Note: many devices react badly when given an unexpected length.
> + */
> +static int
> +scsi_do_inquiry(Scsi_Request *sreq, char *buffer, int len) {
> + Scsi_Device *sdev = sreq->sr_device;
> + unsigned char cmd[6];
> + int res;
> +
> + SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO "scsi scan: INQUIRY (len %d) "
> + "to host %d channel %d id %d lun %d\n",
> + len, sdev->host->host_no, sdev->channel,
> + sdev->id, sdev->lun));
> +
> + memset(cmd, 0, 6);
> + cmd[0] = INQUIRY;
> + cmd[4] = len;
> + sreq->sr_cmd_len = 0;
> + sreq->sr_data_direction = SCSI_DATA_READ;
> + memset(buffer, 0, len);
> +
> + scsi_wait_req(sreq, (void *) cmd, (void *) buffer, len,
> + SCSI_TIMEOUT + 4 * HZ, 3);
> +
> + res = sreq->sr_result;
> + SCSI_LOG_SCAN_BUS(3, printk(res ? KERN_INFO "scsi scan: "
> + "INQUIRY returned code 0x%x\n" :
> + KERN_INFO "scsi scan: INQUIRY OK\n", res));
> + return res;
> +}
>
> +/*
> + * The inquiry length is inq_result[4] + 5 unless overridden.
> + */
> +static int
> +valid_inquiry_lth(int bflags, unsigned char *inq_result) {
> + int len = ((bflags & BLIST_INQUIRY_36) ? 36 :
> + (bflags & BLIST_INQUIRY_58) ? 58 :
> + inq_result[4] + 5);
> + if (len > 255)
> + len = 36; /* sanity */
> + return len;
> +}
>
> Text in scsi_probe_lun(), including two reactions to comments:
>
> static void
> scsi_probe_lun(Scsi_Request *sreq, char *inq_result, int *bflags)
> {
> Scsi_Device *sdev = sreq->sr_device; /* a bit ugly */
> unsigned char scsi_cmd[MAX_COMMAND_SIZE];
> int res, possible_inq_resp_len;
>
> /* first issue an inquiry with conservative alloc_length */
> res = scsi_do_inquiry(sreq, inq_result, 36);
>
> if (res) {
> if ((driver_byte(res) & DRIVER_SENSE) != 0 &&
> (sreq->sr_sense_buffer[2] & 0xf) == UNIT_ATTENTION &&
> sreq->sr_sense_buffer[12] == 0x28 &&
> sreq->sr_sense_buffer[13] == 0) {
> /* not-ready to ready transition - good */
> /* dpg: bogus? INQUIRY never returns UNIT_ATTENTION */
> /* aeb: seen with an USB CF card reader */
> } else
> /*
> * assume no peripheral if any other sort of error
> */
> return;
> }
>
> /*
> * Get any flags for this device.
> *
> * Some devices return only 5 bytes for an INQUIRY, but the memset
> * in scsi_do_inquiry makes sure that scsi_get_device_flags() gets
> * well-defined arguments.
> */
> *bflags = scsi_get_device_flags(&inq_result[8], &inq_result[16]);
>
> possible_inq_resp_len = valid_inquiry_lth(*bflags, inq_result);
>
> if (possible_inq_resp_len > 36) { /* do additional INQUIRY */
> res = scsi_do_inquiry(sreq, inq_result, possible_inq_resp_len);
> if (res)
> return;
>
> /*
> * The INQUIRY can change, this means the length can change.
> */
> possible_inq_resp_len = valid_inquiry_lth(*bflags, inq_result);
> }
>
> sdev->inquiry_len = possible_inq_resp_len;
>
> /*
> * Abort if the response length is less than 36?
> * No, some USB devices just produce the minimal 5-byte INQUIRY.
> *
> * ...
> */
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2003-01-04 0:55 UTC|newest]
Thread overview: 15+ 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 [this message]
2003-01-04 2:14 ` Douglas Gilbert
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 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=20030103170404.D4315@one-eyed-alien.net \
--to=mdharm-kernel@one-eyed-alien.net \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox