From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 04 of 10] scsi: Support devices with protection information (DIF)
Date: Sat, 28 Jun 2008 10:07:38 -0500 [thread overview]
Message-ID: <1214665658.3658.18.camel@localhost.localdomain> (raw)
In-Reply-To: <2fd66ca994dbf1ed6d14.1214407363@sermon.lab.mkp.net>
On Wed, 2008-06-25 at 11:22 -0400, Martin K. Petersen wrote:
> - Add support for an extra scatter-gather list containing protection
> information.
>
> - Remember devices with protection information turned on in INQUIRY.
>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>
> ---
> 4 files changed, 62 insertions(+)
> drivers/scsi/scsi_lib.c | 38 ++++++++++++++++++++++++++++++++++++++
> drivers/scsi/scsi_scan.c | 3 +++
> include/scsi/scsi_cmnd.h | 20 ++++++++++++++++++++
> include/scsi/scsi_device.h | 1 +
>
>
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -778,6 +778,11 @@ void scsi_release_buffers(struct scsi_cm
> kmem_cache_free(scsi_sdb_cache, bidi_sdb);
> cmd->request->next_rq->special = NULL;
> }
> +
> + if (scsi_prot_sg_count(cmd)) {
> + scsi_free_sgtable(cmd->prot_sdb);
> + kmem_cache_free(scsi_sdb_cache, cmd->prot_sdb);
> + }
> }
> EXPORT_SYMBOL(scsi_release_buffers);
>
> @@ -1031,6 +1036,32 @@ static int scsi_init_sgtable(struct requ
> return BLKPREP_OK;
> }
>
> +static int scsi_protect_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
> +{
> + struct request *req;
> + struct scsi_data_buffer *pdb;
> + int ivecs, count;
> +
> + req = cmd->request;
> +
> + pdb = kmem_cache_zalloc(scsi_sdb_cache, gfp_mask);
> + if (unlikely(pdb == NULL))
> + return BLKPREP_DEFER;
I'm afraid you can't do it like this because it will violate our forward
progress guarantees. If this is the last spare command required for
writeout, you need to guarantee either this allocation will succeed, or
we can proceed without the DIF data.
I know you copied it from the bidirectional stuff, but they don't need
forward progress guarantees; something in the mainline does because we
could get into a vmwriteout failure case even for a DIF protected
device.
> +
> + ivecs = blk_rq_count_integrity_sg(req);
> +
> + if (unlikely(scsi_alloc_sgtable(pdb, ivecs, gfp_mask)))
> + return BLKPREP_DEFER;
> +
> + count = blk_rq_map_integrity_sg(req, pdb->table.sgl);
> + BUG_ON(unlikely(count > ivecs));
> +
> + cmd->prot_sdb = pdb;
> + cmd->prot_sdb->table.nents = count;
> +
> + return BLKPREP_OK;
> +}
> +
> /*
> * Function: scsi_init_io()
> *
> @@ -1060,6 +1091,13 @@ int scsi_init_io(struct scsi_cmnd *cmd,
> error = scsi_init_sgtable(cmd->request->next_rq, bidi_sdb,
> GFP_ATOMIC);
> if (error)
> + goto err_exit;
> + }
> +
> + if (blk_integrity_rq(cmd->request)) {
> + error = scsi_protect_io(cmd, gfp_mask);
> +
> + if (error != BLKPREP_OK)
> goto err_exit;
> }
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -882,6 +882,9 @@ static int scsi_add_lun(struct scsi_devi
>
> if (*bflags & BLIST_USE_10_BYTE_MS)
> sdev->use_10_for_ms = 1;
> +
> + if (inq_result[5] & 0x1)
> + sdev->protection = 1;
Is there a reason to have a separate flag here and not just do something
like the usual in scsi_device.h:
static inline int scsi_device_protection(struct scsi_device *sdev)
{
return sdev->inquiry[5] & (1<<0);
}
James
next prev parent reply other threads:[~2008-06-28 15:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-25 15:22 [PATCH 00 of 10] SCSI Data Integrity Support Martin K. Petersen
2008-06-25 15:22 ` [PATCH 01 of 10] sd: Move sd.h header file Martin K. Petersen
2008-06-25 15:22 ` [PATCH 02 of 10] sd: Move scsi_disk() accessor function to sd.h Martin K. Petersen
2008-06-25 15:22 ` [PATCH 03 of 10] lib: Add support for the T10 Data Integrity Field CRC Martin K. Petersen
2008-06-25 15:22 ` [PATCH 04 of 10] scsi: Support devices with protection information (DIF) Martin K. Petersen
2008-06-28 15:07 ` James Bottomley [this message]
2008-06-30 15:24 ` Martin K. Petersen
2008-06-25 15:22 ` [PATCH 05 of 10] scsi: Host protection capabilities Martin K. Petersen
2008-06-25 15:22 ` [PATCH 06 of 10] scsi: Command protection operation Martin K. Petersen
2008-06-25 15:22 ` [PATCH 07 of 10] scsi: Do not retry a request whose data integrity check failed Martin K. Petersen
2008-06-25 15:22 ` [PATCH 08 of 10] scsi: Documentation for the SCSI protection information/DIF support Martin K. Petersen
2008-06-25 15:22 ` [PATCH 09 of 10] sd: Identify DIF protection type and application tag ownership Martin K. Petersen
2008-06-25 15:22 ` [PATCH 10 of 10] sd: Support for SCSI disk (SBC) Data Integrity Field Martin K. Petersen
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=1214665658.3658.18.camel@localhost.localdomain \
--to=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 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.