All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pat LaVarre <p.lavarre@ieee.org>
To: patmans@us.ibm.com
Cc: stern@rowland.harvard.edu, ronald@kuetemeier.com,
	linux-scsi@vger.kernel.org, usb-storage@one-eyed-alien.net,
	james.bottomley@steeleye.com
Subject: Re: [PATCH/RFT] mode sense madness always use page 8
Date: 31 Oct 2003 13:38:21 -0700	[thread overview]
Message-ID: <1067632701.5742.45.camel@patrh9> (raw)
In-Reply-To: <20031030112621.A7844@beaverton.ibm.com>

> > __scsi_mode_sense() ...
> ...
> per Pat L's comment, should we decrement the len by four if going from
> MODE SENSE 10 to MODE SENSE? Or request four more bytes than required?

I've seen no answer here yet, so I figured I'd volunteer a little more
study myself, so now I ask:

Tell me again what we think __scsi_mode_sense does?

Am I correct to guess by intent __scsi_mode_sense does a complete job of
hiding the op x1A MODE_SENSE vs. op x5A MODE_SENSE_10 choice only if the
caller ignores the content of the buffer after the call, choosing
instead to interpret only the struct scsi_mode_data?

Supposing that's correct, then I vote we zero the buffer after copying
its bits into the struct scsi_mode_data.

Meanwhile, from that perspective, we say we bother to pass the dbd,
modepage, len parms into __scsi_mode_sense only to guess at specifically
what combination of sreq->sr_cmnd sr_cmd_len sr_bufflen might work.

Since we offer only one set of guesses, no matter
sreq->sr_device->use_10_for_ms, then yes, we have to reduce our guess by
four if we substitute op x1A MODE_SENSE for op x5A MODE_SENSE_10, else
our guesses are not consistent - not orthogonal vs. use_10_for_ms.

Ouch that doesn't sound like a 2.6.0 change necessary enough to pass
review, does it?

> __scsi_mode_sense() ...

I see { unsigned char cmd[12]; } there.  We mean 16, right?

I argue by way of seeing { memcpy(sreq->sr_cmnd, cmnd,
sizeof(sreq->sr_cmnd)); } in scsi_do_req.  I conclude we need sizeof
*cmnd to meet or exceed sizeof(sreq->sr_cmnd), thus same for
scsi_wait_req.  include/scsi/scsi_request.h tells me that size is
MAX_COMMAND_SIZE, possibly the 16 seen in include/scsi/scsi_cmnd.h.

I guess we're getting away with what we've got because we're mostly
using gcc in places where copying more than exists out of a local
variable picks up some extra stack that has already been allocated,
rather than double-faulting by trying to grow stack while talking scsi
to the paging device.

Pat LaVarre



  reply	other threads:[~2003-10-31 20:38 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1067293080.1075.8.camel@ronald.kuetemeier.com>
     [not found] ` <20031027145531.A2130@beaverton.ibm.com>
2003-10-28  3:51   ` [PATCH] SCSI: limit mode sense usage Ronald Kuetemeier
2003-10-28 15:03     ` [usb-storage] " Alan Stern
2003-10-28 15:16       ` Patrick Mansfield
2003-10-28 15:40         ` Alan Stern
2003-10-28 15:55           ` Ronald Kuetemeier
2003-10-28 16:15           ` Ronald Kuetemeier
2003-10-28 19:17             ` Alan Stern
2003-10-28 19:55               ` Ronald Kuetemeier
2003-10-28 20:29                 ` Alan Stern
2003-10-28 21:33                   ` Ronald Kuetemeier
2003-10-28 22:49                     ` Alan Stern
2003-10-28 23:37                       ` Pat LaVarre
2003-10-29  1:51                       ` Patrick Mansfield
2003-10-29  2:16                         ` Ronald Kuetemeier
2003-10-29  7:27                           ` Patrick Mansfield
2003-10-29  7:21                         ` Patrick Mansfield
2003-10-29 15:16                           ` Alan Stern
2003-10-29 16:04                             ` Ronald Kuetemeier
2003-10-29 15:09                         ` Alan Stern
2003-10-29 15:53                           ` Ronald Kuetemeier
2003-10-29 16:30                             ` Patrick Mansfield
2003-10-28 15:42         ` Ronald Kuetemeier
2003-10-29 16:46           ` [PATCH/RFT] check non-scsi part of status in scsi_status_is_good Patrick Mansfield
2003-10-29 17:53             ` Ronald Kuetemeier
2003-10-29 23:16               ` Patrick Mansfield
2003-10-30 15:11                 ` Alan Stern
2003-10-30 16:35                   ` Pat LaVarre
2003-10-30 17:18                     ` Patrick Mansfield
2003-10-30 17:38                       ` Pat LaVarre
2003-10-30 18:05                         ` [PATCH/RFT] mode sense madness always use page 8 Patrick Mansfield
2003-10-30 18:14                           ` Ronald Kuetemeier
2003-10-30 18:25                             ` Patrick Mansfield
2003-10-30 18:15                           ` Pat LaVarre
2003-10-30 18:56                           ` Alan Stern
2003-10-30 19:06                             ` Pat LaVarre
2003-10-30 20:00                               ` Alan Stern
2003-10-31 20:47                                 ` Pat LaVarre
2003-10-30 19:26                             ` Patrick Mansfield
2003-10-31 20:38                               ` Pat LaVarre [this message]
2003-11-03 21:40                                 ` Pat LaVarre
2003-10-30 19:25                           ` Ronald Kuetemeier
2003-10-30 19:39                             ` Pat LaVarre
2003-10-30 21:48                             ` Patrick Mansfield
2003-10-30 21:58                               ` Ronald Kuetemeier
2003-10-30 23:59                                 ` Pat LaVarre
2003-10-31 18:16                                   ` Patrick Mansfield
2003-10-31 23:11                                     ` Pat LaVarre
2003-11-06 23:11                                     ` Douglas Gilbert
2003-11-07 16:13                                       ` Pat LaVarre
2003-10-28 15:38       ` [PATCH] SCSI: limit mode sense usage Pat LaVarre
2003-10-28 20:56         ` Pat LaVarre
2003-10-28 22:28           ` Alan Stern
2003-10-28 22:54             ` Pat LaVarre
2003-10-29 14:49               ` Alan Stern
2003-10-29 15:43                 ` Pat LaVarre

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=1067632701.5742.45.camel@patrh9 \
    --to=p.lavarre@ieee.org \
    --cc=james.bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=patmans@us.ibm.com \
    --cc=ronald@kuetemeier.com \
    --cc=stern@rowland.harvard.edu \
    --cc=usb-storage@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.