Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1375049 > unrolled thread

[PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-04-10 21:40 +0200
Last post2016-04-12 16:20 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-04-10 21:40 +0200
    Re: [PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS Jiri Slaby <jslaby@suse.cz> - 2016-04-11 14:00 +0200
      Re: [PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-04-12 16:20 +0200

#1375049 — [PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-04-10 21:40 +0200
Subject[PATCH 3.14 15/76] USB: uas: Reduce can_queue to MAX_CMNDS
Message-ID<rmtnd-1ww-37@gated-at.bofh.it>
3.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Hans de Goede <hdegoede@redhat.com>

commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 upstream.

The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
are shared between luns, so there is no need to claim that we can_queue
some random large number.

Not claiming that we can_queue 65536 commands, fixes the uas driver
failing to initialize while allocating the tag map with a "Page allocation
failure (order 7)" error on systems which have been running for a while
and thus have fragmented memory.

Reported-and-tested-by: Yves-Alexis Perez <corsac@corsac.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/storage/uas.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -835,7 +835,7 @@ static struct scsi_host_template uas_hos
 	.eh_abort_handler = uas_eh_abort_handler,
 	.eh_device_reset_handler = uas_eh_device_reset_handler,
 	.eh_bus_reset_handler = uas_eh_bus_reset_handler,
-	.can_queue = 65536,	/* Is there a limit on the _host_ ? */
+	.can_queue = MAX_CMNDS,
 	.this_id = -1,
 	.sg_tablesize = SG_NONE,
 	.cmd_per_lun = 1,	/* until we override it */

[toc] | [next] | [standalone]


#1375749

FromJiri Slaby <jslaby@suse.cz>
Date2016-04-11 14:00 +0200
Message-ID<rmIFA-5ju-1@gated-at.bofh.it>
In reply to#1375049
On 04/10/2016, 08:36 PM, Greg Kroah-Hartman wrote:
> 3.14-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Hans de Goede <hdegoede@redhat.com>
> 
> commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 upstream.
> 
> The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
> are shared between luns, so there is no need to claim that we can_queue
> some random large number.
> 
> Not claiming that we can_queue 65536 commands, fixes the uas driver
> failing to initialize while allocating the tag map with a "Page allocation
> failure (order 7)" error on systems which have been running for a while
> and thus have fragmented memory.
> 
> Reported-and-tested-by: Yves-Alexis Perez <corsac@corsac.net>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  drivers/usb/storage/uas.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -835,7 +835,7 @@ static struct scsi_host_template uas_hos
>  	.eh_abort_handler = uas_eh_abort_handler,
>  	.eh_device_reset_handler = uas_eh_device_reset_handler,
>  	.eh_bus_reset_handler = uas_eh_bus_reset_handler,
> -	.can_queue = 65536,	/* Is there a limit on the _host_ ? */
> +	.can_queue = MAX_CMNDS,

MAX_CMNDS is defined only since 3.18. (The driver is marked as BROKEN
till 3.15, anyway.)

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


#1376844

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-04-12 16:20 +0200
Message-ID<rn7kC-eE-37@gated-at.bofh.it>
In reply to#1375749
On Mon, Apr 11, 2016 at 01:52:32PM +0200, Jiri Slaby wrote:
> On 04/10/2016, 08:36 PM, Greg Kroah-Hartman wrote:
> > 3.14-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Hans de Goede <hdegoede@redhat.com>
> > 
> > commit 55ff8cfbc4e12a7d2187df523938cc671fbebdd1 upstream.
> > 
> > The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
> > are shared between luns, so there is no need to claim that we can_queue
> > some random large number.
> > 
> > Not claiming that we can_queue 65536 commands, fixes the uas driver
> > failing to initialize while allocating the tag map with a "Page allocation
> > failure (order 7)" error on systems which have been running for a while
> > and thus have fragmented memory.
> > 
> > Reported-and-tested-by: Yves-Alexis Perez <corsac@corsac.net>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > ---
> >  drivers/usb/storage/uas.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- a/drivers/usb/storage/uas.c
> > +++ b/drivers/usb/storage/uas.c
> > @@ -835,7 +835,7 @@ static struct scsi_host_template uas_hos
> >  	.eh_abort_handler = uas_eh_abort_handler,
> >  	.eh_device_reset_handler = uas_eh_device_reset_handler,
> >  	.eh_bus_reset_handler = uas_eh_bus_reset_handler,
> > -	.can_queue = 65536,	/* Is there a limit on the _host_ ? */
> > +	.can_queue = MAX_CMNDS,
> 
> MAX_CMNDS is defined only since 3.18. (The driver is marked as BROKEN
> till 3.15, anyway.)

Ah, good point, now removed, thanks.

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web