From: Christoph Hellwig <hch@lst.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Gerd Hoffmann <kraxel@redhat.com>, Christoph Hellwig <hch@lst.de>,
linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] uas: Limit qdepth at the scsi-host level
Date: Mon, 21 Mar 2016 15:36:03 +0100 [thread overview]
Message-ID: <20160321143603.GB12654@lst.de> (raw)
In-Reply-To: <1458407176.2288.5.camel@HansenPartnership.com>
On Sat, Mar 19, 2016 at 10:06:16AM -0700, James Bottomley wrote:
> Help me understand this bug a bit more. Are you saying that the commit
> you identify is causing the block layer to queue more commands than
> you've set the per-lun limit to? In which case we have a serious
> problem for more than just UAS. Or are you saying that UAS always had
> a global command limit, but it just didn't get set correctly; however,
> it mostly worked until the above commit exposed the problem?
I did mishandle uas in my patch to make the host wide tags the default
and didn't notice that uas set a different limit for the host wide
tag limit and ->can_queue. With the old code we'd apply the lower
of the two limits, which was the host wide tag limit, but my patch
removed that one and now purely relies on can_queue.
Now most uas devices only have a single lun, and the per-lun limit
was set to what the global limit should be as well, so most users
didn't really notice this.
prev parent reply other threads:[~2016-03-21 14:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-19 8:59 [PATCH] uas: Limit qdepth at the scsi-host level Hans de Goede
[not found] ` <1458377952-12567-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-19 15:52 ` Sergei Shtylyov
2016-03-21 14:36 ` Christoph Hellwig
2016-03-19 17:06 ` James Bottomley
2016-03-20 13:28 ` Hans de Goede
2016-03-21 14:36 ` Christoph Hellwig [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=20160321143603.GB12654@lst.de \
--to=hch@lst.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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).