All of lore.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  1:04 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 [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 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 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.