All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-scsi@vger.kernel.org, Bart Van Assche <bvanassche@acm.org>,
	Ming Lei <ming.lei@redhat.com>, Bean Huo <beanhuo@micron.com>,
	Hannes Reinecke <hare@suse.de>,
	Sumanesh Samanta <sumanesh.samanta@broadcom.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>
Subject: [PATCH v4 01/17] scsi: core: Fix scsi_device_max_queue_depth()
Date: Fri,  3 Dec 2021 15:19:34 -0800	[thread overview]
Message-ID: <20211203231950.193369-2-bvanassche@acm.org> (raw)
In-Reply-To: <20211203231950.193369-1-bvanassche@acm.org>

The comment above scsi_device_max_queue_depth() and also the description
of commit ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <=
max(shost->can_queue, 1024)") contradict the implementation of the function
scsi_device_max_queue_depth(). Additionally, the maximum queue depth of a
SCSI LUN never exceeds host->can_queue. Fix scsi_device_max_queue_depth()
by changing max_t() into min_t().

Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Tested-by: Bean Huo <beanhuo@micron.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com>
Fixes: ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/scsi/scsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index dee4d9c6046d..211aace69c22 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -200,11 +200,11 @@ void scsi_finish_command(struct scsi_cmnd *cmd)
 
 
 /*
- * 1024 is big enough for saturating the fast scsi LUN now
+ * 1024 is big enough for saturating fast SCSI LUNs.
  */
 int scsi_device_max_queue_depth(struct scsi_device *sdev)
 {
-	return max_t(int, sdev->host->can_queue, 1024);
+	return min_t(int, sdev->host->can_queue, 1024);
 }
 
 /**

  reply	other threads:[~2021-12-03 23:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 23:19 [PATCH v4 00/17] UFS patches for kernel v5.17 Bart Van Assche
2021-12-03 23:19 ` Bart Van Assche [this message]
2021-12-03 23:19 ` [PATCH v4 02/17] scsi: ufs: Rename a function argument Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 03/17] scsi: ufs: Remove is_rpmb_wlun() Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 04/17] scsi: ufs: Remove the sdev_rpmb member Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 05/17] scsi: ufs: Remove dead code Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 06/17] scsi: ufs: Fix race conditions related to driver data Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 07/17] scsi: ufs: Remove ufshcd_any_tag_in_use() Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 08/17] scsi: ufs: Rework ufshcd_change_queue_depth() Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 09/17] scsi: ufs: Fix a deadlock in the error handler Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 10/17] scsi: ufs: Remove hba->cmd_queue Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 11/17] scsi: ufs: Remove the 'update_scaling' local variable Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 12/17] scsi: ufs: Introduce ufshcd_release_scsi_cmd() Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 13/17] scsi: ufs: Improve SCSI abort handling further Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 14/17] scsi: ufs: Fix a kernel crash during shutdown Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 15/17] scsi: ufs: Stop using the clock scaling lock in the error handler Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 16/17] scsi: ufs: Optimize the command queueing code Bart Van Assche
2021-12-06 22:41   ` Asutosh Das (asd)
2021-12-08 17:28     ` Asutosh Das (asd)
2021-12-08 17:53       ` Bart Van Assche
2021-12-14  4:04   ` Bjorn Andersson
2021-12-14  4:57     ` Bart Van Assche
2021-12-15  3:52       ` Bjorn Andersson
2021-12-15 18:44         ` Bart Van Assche
2021-12-03 23:19 ` [PATCH v4 17/17] scsi: ufs: Implement polling support Bart Van Assche
2021-12-07  3:31 ` [PATCH v4 00/17] UFS patches for kernel v5.17 Martin K. Petersen
2021-12-14  4:40 ` Martin K. Petersen
2021-12-14  7:14   ` Avri Altman
2021-12-14  7:18     ` 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=20211203231950.193369-2-bvanassche@acm.org \
    --to=bvanassche@acm.org \
    --cc=adrian.hunter@intel.com \
    --cc=beanhuo@micron.com \
    --cc=hare@suse.de \
    --cc=jaegeuk@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=sumanesh.samanta@broadcom.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.