From: Christoph Hellwig <hch@lst.de>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 06/10] sd: don't use scsi_setup_blk_pc_cmnd for discard requests
Date: Mon, 7 Jul 2014 11:24:28 +0200 [thread overview]
Message-ID: <20140707092427.GA14476@lst.de> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B402958B8AD4C@G9W0745.americas.hpqcorp.net>
On Mon, Jul 07, 2014 at 12:01:53AM +0000, Elliott, Robert (Server Storage) wrote:
> > nr_sectors >>= ilog2(sdp->sector_size) - 9;
> > - rq->timeout = SD_TIMEOUT;
> > -
> > - memset(rq->cmd, 0, rq->cmd_len);
>
> Is *cmd guaranteed to be zero at this point?
Yes, scsi_setup_fs_cmnd takes care of this before calling into the driver.
> With scsi-mq.2 I've seen UNMAP CDBs with garbage in CDB bytes
> 2 to 5 (which causes a drive that checks reserved fields to
> reject the command), which suggests there is a case in which
> that is not guaranteed.
Indeed, we only do it up to the actual CDB length, which is due to:
sd: don't use rq->cmd_len before setting it up
I had to add this because blk-mq doesn't initialize cmd_len, unlike the
old path.
Either we need to merge this series as well to take care of all this,
or I should do a replacement for the above patch that just memsets up to
BLK_MAX_CDB.
> If so, then getting rid of the double memset is another
> benefit, and removing it from scsi_setup_fs_cmnd would
> be good too. Since that function is EXPORTED, does that
> prevent removing its memset?
We do need one of the memsets. With this series I'm keeping the one
in scsi_setup_fs_cmnd so that it's done in one single place, which
seems preferable over having it duplicated in various spots. At the
end of the series scsi_setup_fs_cmnd ceases to be exported.
next prev parent reply other threads:[~2014-07-07 9:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-29 13:34 RFC: clean up command setup Christoph Hellwig
2014-06-29 13:34 ` [PATCH 01/10] scsi: move the nr_phys_segments assert into scsi_init_io Christoph Hellwig
2014-07-11 12:17 ` Hannes Reinecke
2014-07-13 14:03 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 02/10] scsi: restructure command initialization for TYPE_FS requests Christoph Hellwig
2014-07-11 12:18 ` Hannes Reinecke
2014-07-13 14:04 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 03/10] scsi: set sc_data_direction in common code Christoph Hellwig
2014-07-11 12:19 ` Hannes Reinecke
2014-07-13 14:06 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 04/10] sd: don't use scsi_setup_blk_pc_cmnd for flush requests Christoph Hellwig
2014-07-11 12:20 ` Hannes Reinecke
2014-07-13 14:07 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 05/10] sd: don't use scsi_setup_blk_pc_cmnd for write same requests Christoph Hellwig
2014-07-11 12:25 ` Hannes Reinecke
2014-07-11 15:15 ` Christoph Hellwig
2014-07-13 14:14 ` Martin K. Petersen
2014-07-17 15:29 ` Christoph Hellwig
2014-06-29 13:34 ` [PATCH 06/10] sd: don't use scsi_setup_blk_pc_cmnd for discard requests Christoph Hellwig
2014-07-07 0:01 ` Elliott, Robert (Server Storage)
2014-07-07 2:01 ` Elliott, Robert (Server Storage)
2014-07-07 9:24 ` Christoph Hellwig [this message]
2014-07-11 12:26 ` Hannes Reinecke
2014-07-11 15:15 ` Christoph Hellwig
2014-07-13 14:35 ` Martin K. Petersen
2014-07-13 14:52 ` Douglas Gilbert
2014-07-13 14:56 ` Christoph Hellwig
2014-07-13 15:03 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 07/10] sd: retry write same commands Christoph Hellwig
2014-07-11 12:26 ` Hannes Reinecke
2014-07-13 14:36 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 08/10] sd: retry discard commands Christoph Hellwig
2014-07-11 12:27 ` Hannes Reinecke
2014-07-13 14:36 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 09/10] sd: split sd_init_command Christoph Hellwig
2014-07-11 12:33 ` Hannes Reinecke
2014-07-13 14:37 ` Martin K. Petersen
2014-06-29 13:34 ` [PATCH 10/10] scsi: mark scsi_setup_blk_pc_cmnd static Christoph Hellwig
2014-07-11 12:33 ` Hannes Reinecke
2014-07-13 14:38 ` Martin K. Petersen
2014-07-11 9:16 ` RFC: clean up command setup Christoph Hellwig
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=20140707092427.GA14476@lst.de \
--to=hch@lst.de \
--cc=Elliott@hp.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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;
as well as URLs for NNTP newsgroup(s).