From: Ming Lei <ming.lei@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: jejb@linux.ibm.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
kashyap.desai@broadcom.com, dgilbert@interlog.com
Subject: Re: [PATCH] scsi: core: Cap initial sdev queue depth at shost.can_queue
Date: Fri, 23 Apr 2021 09:54:01 +0800 [thread overview]
Message-ID: <YIIouSOM77zEw3Qb@T590> (raw)
In-Reply-To: <186be6c5-dbcd-d1fb-67c5-72b5a761568a@huawei.com>
On Thu, Apr 22, 2021 at 05:35:42PM +0100, John Garry wrote:
> On 22/04/2021 02:38, Ming Lei wrote:
> > > I would rather not change the values which are provided from the driver. I
> > > would rather take the original values and try to use them in a sane way.
> > >
> > > I have not seen other places where driver shost config values are modified
> > > by the core code.
>
> Hi Ming,
>
> > Wrt. .cmd_per_lun, I think it is safe to modify it into one correct
> > depth because almost all drivers are just producer of .cmd_per_lun. And
> > except for debug purpose, there are only three consumers of .cmd_per_lun
> > in scsi, and all are for scsi_change_queue_depth():
> >
> > process_message()
> > scsi_alloc_sdev()
> > virtscsi_change_queue_depth()
>
> sg_ioctl_common() also looks to read it, but I can't imagine we could break
> that interface with either suggested change.
Then one bad .cmd_per_lun can be passed to userspace, as your patch
doesn't cover this case.
>
> So I still prefer not to modify shost.cmd_per_lun, but if you feel strongly
> enough then I can look to make that change.
I still suggest to make .cmd_per_lun correct since the beginning,
otherwise you may have to cover anywhere .cmd_per_lun is used.
Thanks,
Ming
prev parent reply other threads:[~2021-04-23 1:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 16:06 [PATCH] scsi: core: Cap initial sdev queue depth at shost.can_queue John Garry
2021-04-20 0:02 ` Ming Lei
2021-04-20 8:14 ` John Garry
2021-04-22 1:38 ` Ming Lei
2021-04-22 16:35 ` John Garry
2021-04-23 1:54 ` Ming Lei [this message]
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=YIIouSOM77zEw3Qb@T590 \
--to=ming.lei@redhat.com \
--cc=dgilbert@interlog.com \
--cc=jejb@linux.ibm.com \
--cc=john.garry@huawei.com \
--cc=kashyap.desai@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--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.