public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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