linux-kernel - Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 06 Mar 2014 00:27:59 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	Linux-usb <linux-usb@...r.kernel.org>
CC:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Subject: Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)

On 05/03/14 11:17 PM, Robert Hancock wrote:
> I have a USB 3.0 multi-card reader device:
>
> Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc.
>
> which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200
> specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202).
> Below is what I get in dmesg. Essentially there's a bunch of
> input/output errors making the reader mostly unusable.
>
> This is on an Intel Haswell machine with this controller:
>
> 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
> Chipset Family USB xHCI [8086:8c31] (rev 05)
>
> It looks like there were some XHCI commits that went into 3.13.5 so it
> seems likely one of those is the cause. I can try current git if there's
> anything in there that's likely to fix it. But it does seem like a
> regression got into the stable kernel in this respect.

Bisecting between 3.13.4 and 3.13.5 gives me this:

c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit
commit c8f44f98901994832ccecb87c3dd7900274b699a
Author: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Date:   Fri Jan 31 11:26:25 2014 -0800

     xhci 1.0: Limit arbitrarily-aligned scatter gather.

     commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream.

     xHCI 1.0 hosts have a set of requirements on how to align transfer
     buffers on the endpoint rings called "TD fragment" rules.  When the
     ax88179_178a driver added support for scatter gather in 3.12, with
     commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
     enable tso if usb host supports sg dma", it broke the device under xHCI
     1.0 hosts.  Under certain network loads, the device would see an
     unexpected short packet from the host, which would cause the device to
     stop sending ethernet packets, even through USB packets would still be
     sent.

     Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB
     payload burst" attempted to fix this.  It was a quick hack to partially
     implement the TD fragment rules.  However, it caused regressions in the
     usb-storage layer and userspace USB drivers using libusb.  The patches
     to attempt to fix this are too far reaching into the USB core, and we
     really need to implement the TD fragment rules correctly in the xHCI
     driver, instead of continuing to wallpaper over the issues.

     Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
     hosts.  Only the ax88179_178a driver checks the no_sg_constraint flag,
     so don't set it for 1.0 hosts.  This should not impact usb-storage or
     usbfs behavior, since they pass down max packet sized aligned sg-list
     entries (512 for USB 2.0 and 1024 for USB 3.0).

     Signed-off-by: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
     Tested-by: Mark Lord <mlord@...ox.com>
     Cc: David Laight <David.Laight@...LAB.COM>
     Cc: Bjørn Mork <bjorn@...k.no>
     Cc: Freddy Xin <freddy@...x.com.tw>
     Cc: Ming Lei <ming.lei@...onical.com>
     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/