linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Douglas Gilbert <dgilbert@interlog.com>, linux-scsi@vger.kernel.org
Cc: martin.petersen@oracle.com, jejb@linux.vnet.ibm.com,
	bvanassche@acm.org, hch@infradead.org
Subject: Re: [PATCH v4 12/22] sg: sense buffer rework
Date: Mon, 9 Sep 2019 17:01:40 +0200	[thread overview]
Message-ID: <7d6437e7-18ac-742f-0f99-e77e0a265509@suse.de> (raw)
In-Reply-To: <20190829022659.23130-13-dgilbert@interlog.com>

On 8/29/19 4:26 AM, Douglas Gilbert wrote:
> The biggest single item in the sg_request object is the sense
> buffer array which is SCSI_SENSE_BUFFERSIZE bytes long. That
> constant started out at 18 bytes 20 years ago and is 96 bytes
> now and might grow in the future. On the other hand the sense
> buffer is only used by a small number of SCSI commands: those
> that fail and those that want to return more information
> other than a SCSI status of GOOD.
> 
> Set up a small mempool called "sg_sense" that is only used as
> required and released back to the mempool as soon as practical.
> 
> Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
> ---
>  drivers/scsi/sg.c | 86 ++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 73 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 2e476e74130b..ebb9d4f53177 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -72,6 +72,10 @@ static char *sg_version_date = "20190606";
>   */
>  #define SG_MAX_CDB_SIZE 252
>  
> +static struct kmem_cache *sg_sense_cache;
> +#define SG_MEMPOOL_MIN_NR 4
> +static mempool_t *sg_sense_pool;
> +
>  #define uptr64(val) ((void __user *)(uintptr_t)(val))
>  #define cuptr64(val) ((const void __user *)(uintptr_t)(val))
>  
> @@ -176,7 +180,6 @@ struct sg_request {	/* active SCSI command or inactive on free list (fl) */
>  	spinlock_t req_lck;
>  	struct sg_scatter_hold sgat_h;	/* hold buffer, perhaps scatter list */
>  	struct sg_slice_hdr3 s_hdr3;  /* subset of sg_io_hdr */
> -	u8 sense_b[SCSI_SENSE_BUFFERSIZE];
>  	u32 duration;		/* cmd duration in milliseconds */
>  	u32 rq_flags;		/* hold user supplied flags */
>  	u32 rq_info;		/* info supplied by v3 and v4 interfaces */
> @@ -188,6 +191,7 @@ struct sg_request {	/* active SCSI command or inactive on free list (fl) */
>  	u8 cmd_opcode;		/* first byte of SCSI cdb */
>  	u64 start_ns;		/* starting point of command duration calc */
>  	unsigned long frq_bm[1];	/* see SG_FRQ_* defines above */
> +	u8 *sense_bp;		/* mempool alloc-ed sense buffer, as needed */
>  	struct sg_fd *parentfp;	/* pointer to owning fd, even when on fl */
>  	struct request *rq;	/* released in sg_rq_end_io(), bio kept */
>  	struct bio *bio;	/* kept until this req -->SG_RS_INACTIVE */
> @@ -845,18 +849,21 @@ sg_copy_sense(struct sg_request *srp)
>  	    (driver_byte(srp->rq_result) & DRIVER_SENSE)) {
>  		int sb_len = min_t(int, SCSI_SENSE_BUFFERSIZE, srp->sense_len);
>  		int mx_sb_len;
> +		u8 *sbp = srp->sense_bp;
>  		void __user *up;
>  
> +		srp->sense_bp = NULL;
>  		up = (void __user *)srp->s_hdr3.sbp;
>  		mx_sb_len = srp->s_hdr3.mx_sb_len;
> -		if (up && mx_sb_len > 0) {
> +		if (up && mx_sb_len > 0 && sbp) {
>  			sb_len = min_t(int, sb_len, mx_sb_len);
>  			/* Additional sense length field */
> -			sb_len_wr = 8 + (int)srp->sense_b[7];
> +			sb_len_wr = 8 + (int)sbp[7];
>  			sb_len_wr = min_t(int, sb_len, sb_len_wr);
> -			if (copy_to_user(up, srp->sense_b, sb_len_wr))
> +			if (copy_to_user(up, sbp, sb_len_wr))
>  				sb_len_wr = -EFAULT;
>  		}
> +		mempool_free(sbp, sg_sense_pool);
>  	}
>  	return sb_len_wr;
>  }
> @@ -963,8 +970,14 @@ sg_rd_v1v2(void __user *buf, int count, struct sg_fd *sfp,
>  	h2p->driver_status = driver_byte(rq_result);
>  	if ((CHECK_CONDITION & status_byte(rq_result)) ||
>  	    (DRIVER_SENSE & driver_byte(rq_result))) {
> -		memcpy(h2p->sense_buffer, srp->sense_b,
> -		       sizeof(h2p->sense_buffer));
> +		if (srp->sense_bp) {
> +			u8 *sbp = srp->sense_bp;
> +
> +			srp->sense_bp = NULL;
> +			memcpy(h2p->sense_buffer, sbp,
> +			       sizeof(h2p->sense_buffer));
> +			mempool_free(sbp, sg_sense_pool);
> +		}
>  	}
>  	switch (host_byte(rq_result)) {
>  	/*
> @@ -999,17 +1012,21 @@ sg_rd_v1v2(void __user *buf, int count, struct sg_fd *sfp,
>  
>  	/* Now copy the result back to the user buffer.  */
>  	if (count >= SZ_SG_HEADER) {
> -		if (copy_to_user(buf, h2p, SZ_SG_HEADER))
> -			return -EFAULT;
> +		if (copy_to_user(buf, h2p, SZ_SG_HEADER)) {
> +			res = -EFAULT;
> +			goto fini;
> +		}
>  		buf += SZ_SG_HEADER;
>  		if (count > h2p->reply_len)
>  			count = h2p->reply_len;
>  		if (count > SZ_SG_HEADER) {
> -			if (sg_rd_append(srp, buf, count - SZ_SG_HEADER))
> -				return -EFAULT;
> +			res = sg_rd_append(srp, buf, count - SZ_SG_HEADER);
> +			if (res)
> +				goto fini;
>  		}
>  	} else
>  		res = (h2p->result == 0) ? 0 : -EIO;
> +fini:
>  	atomic_set(&srp->rq_st, SG_RS_DONE_RD);
>  	sg_finish_scsi_blk_rq(srp);
>  	sg_deact_request(sfp, srp);
> @@ -1971,8 +1988,17 @@ sg_rq_end_io(struct request *rq, blk_status_t status)
>  	srp->duration = sg_calc_rq_dur(srp);
>  	if (unlikely((srp->rq_result & SG_ML_RESULT_MSK) && slen > 0))
>  		sg_check_sense(sdp, srp, slen);
> -	if (slen > 0)
> -		memcpy(srp->sense_b, scsi_rp->sense, slen);
> +	if (slen > 0) {
> +		if (scsi_rp->sense) {
> +			srp->sense_bp = mempool_alloc(sg_sense_pool,
> +						      GFP_ATOMIC);
> +			if (srp->sense_bp)
> +				memcpy(srp->sense_bp, scsi_rp->sense, slen);
> +		} else {
> +			pr_warn("%s: scsi_request::sense==NULL\n", __func__);
> +			slen = 0;
> +		}
> +	}
>  	srp->sense_len = slen;
>  	if (unlikely(test_bit(SG_FRQ_IS_ORPHAN, srp->frq_bm))) {
>  		spin_lock(&srp->req_lck);
That looks ... odd.
What happens if 'mempool_alloc()' fails?
Shouldn't we set 'slen' to '0' here, too?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      Teamlead Storage & Networking
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 247165 (AG München), GF: Felix Imendörffer

  reply	other threads:[~2019-09-09 15:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29  2:26 [PATCH v4 00/22] sg: add v4 interface Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 01/22] sg: move functions around Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 02/22] sg: remove typedefs, type+formatting cleanup Douglas Gilbert
2019-08-29  7:36   ` Johannes Thumshirn
2019-08-29  2:26 ` [PATCH v4 03/22] sg: sg_log and is_enabled Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 04/22] sg: rework sg_poll(), minor changes Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 05/22] sg: bitops in sg_device Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 06/22] sg: make open count an atomic Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 07/22] sg: move header to uapi section Douglas Gilbert
2019-08-29 11:15   ` kbuild test robot
2019-08-29 15:47     ` Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 08/22] sg: speed sg_poll and sg_get_num_waiting Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 09/22] sg: sg_allow_if_err_recovery and renames Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 10/22] sg: remove access_ok functions Douglas Gilbert
2019-09-09 14:55   ` Hannes Reinecke
2019-08-29  2:26 ` [PATCH v4 11/22] sg: replace rq array with lists Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 12/22] sg: sense buffer rework Douglas Gilbert
2019-09-09 15:01   ` Hannes Reinecke [this message]
2019-09-09 18:37     ` Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 13/22] sg: add sg v4 interface support Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 14/22] sg: rework debug info Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 15/22] sg: add 8 byte SCSI LUN to sg_scsi_id Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 16/22] sg: expand sg_comm_wr_t Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 17/22] sg: add sg_iosubmit_v3 and sg_ioreceive_v3 ioctls Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 18/22] sg: add some __must_hold macros Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 19/22] sg: move procfs objects to avoid forward decls Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 20/22] sg: first debugfs support Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 21/22] sg: warn v3 write system call users Douglas Gilbert
2019-08-29  2:26 ` [PATCH v4 22/22] sg: bump version to 4.0.03 Douglas Gilbert

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=7d6437e7-18ac-742f-0f99-e77e0a265509@suse.de \
    --to=hare@suse.de \
    --cc=bvanassche@acm.org \
    --cc=dgilbert@interlog.com \
    --cc=hch@infradead.org \
    --cc=jejb@linux.vnet.ibm.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).