[PATCH v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

[Jeffy Chen]

From: AMAN DEEP 

There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(>lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.

When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):

if (list_empty(>td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}

The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.

The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().

As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.

This properly handle the updated ohci->ed_rm_list in usb_kill_urb().

Fixes:977dcfdc6031("USB:OHCI:don't lose track of EDs when a controller dies")
Acked-by: Alan Stern 
CC: 
Signed-off-by: Aman Deep 
Signed-off-by: Jeffy Chen 
---

Changes in v6:
This is a resend of Aman Deep's v5 patch [0], which solved the hang we
hit [1]. (Thanks Aman :)

The v5 has some format issues, so i slightly adjust the commit message.

[0] https://www.spinics.net/lists/linux-usb/msg129010.html
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=803749

 drivers/usb/host/ohci-q.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index b2ec8c399363..4ccb85a67bb3 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1019,6 +1019,8 @@ static void finish_unlinks(struct ohci_hcd *ohci)
 * have modified this list.  normally it's just prepending
 * entries (which we'd ignore), but paranoia won't hurt.
 */
+   *last = ed->ed_next;
+   ed->ed_next = NULL;
modified = 0;
 
/* unlink urbs as requested, but rescan the list after
@@ -1077,21 +1079,22 @@ static void finish_unlinks(struct ohci_hcd *ohci)
goto rescan_this;
 
/*
-* If no TDs are queued, take ED off the ed_rm_list.
+* If no TDs are queued, ED is now idle.
 * Otherwise, if the HC is running, reschedule.
-* If not, leave it on the list for further dequeues.
+* If the HC isn't running, add ED back to the
+* start of the list for later processing.
 */
if (list_empty(>td_list)) {
-   *last = ed->ed_next;
-   ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(>in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
-   *last = ed->ed_next;
-   ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
-   last = >ed_next;
+   ed->ed_next = ohci->ed_rm_list;
+   ohci->ed_rm_list = ed;
+   /* Don't loop on the same ED */
+   if (last == >ed_rm_list)
+   last = >ed_next;
}
 
if (modified)
-- 
2.11.0


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[Bin Liu]

Maxim,

On Fri, Jan 26, 2018 at 12:24:54PM +0300, Maxim Uvarov wrote:
> Bin,
> 
> I looked to my local git and code does not have this latest line "goto
> finish".  It was tested without it and everything worked. Right now I
> can not get access to that hardware to check with and without. But
> only can confirm that without "goto finish" function works with bunch
> of drivers (usb ethernet, hids, hdd).

Thanks for the confirmation. The revert patch has been sent out.

Regards,
-Bin.

> 
> Best regards,
> Maxim.
> 
> 2018-01-25 19:31 GMT+03:00 Bin Liu :
> > Maxim,
> >
> > On Thu, Jan 25, 2018 at 07:24:02PM +0300, Maxim Uvarov wrote:
> >> [1] says that issue is with back ported driver to 3.12.10. Can the
> >> latest kernel be tested on the same hw?
> >
> > Agreed that it should be tested with the latest kernel. But my concern
> > now is if stopping scheduling urbs on errors is a right thing to do,
> > that is why I asked if you can re-test your usecase with reverting the
> > commit. I am unable to reproduce the original issue you had.
> >
> > Thanks,
> > -Bin.
> 
> 
> 
> -- 
> Best regards,
> Maxim Uvarov
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VM Fails to Start When Passing Through PCIe Card

[Blake lee]

Greg,

I apologize as I've forgot to cc the mailing list.

Anyway some people in the VFIO Discord were having similar issues and
reverting the commit below fixed their issue.
https://github.com/torvalds/linux/commit/052f71e25a7ecd80a9567b291df8ea333d9a8565

I just tested and it has resolved my issue as well. It would seem as
though that patch is the offender. Also below I have the kernel oops
in a pastebin for you.
https://pastebin.com/D51uZCFU


Thanks!
Blake Lee

On Wed, Feb 7, 2018 at 7:50 PM, Blake lee  wrote:
> Greg,
>
> I reverted that commit, tested and everything seems to be working
> fine. I would say that's the offending patch. Below is a pastbin to
> the kernel oops in case you need it as well.
>
> output of the kernel oops:
> https://pastebin.com/RDN6Xaqw
>
> Looking forward to an upstream fix
> Thanks!
> Blake Lee
>
> On Wed, Feb 7, 2018 at 6:19 PM, Blake lee  wrote:
>> Yes, I can a bit later. In the VFIO Discord they were saying this
>> commit helped fix their issues that were similar. I need to test that
>> later tonight when I get a chance and see if that solves mine.
>>
>> https://github.com/torvalds/linux/commit/052f71e25a7ecd80a9567b291df8ea333d9a8565
>>
>> Thanks,
>> Blake Lee
>>
>> On Wed, Feb 7, 2018 at 5:59 PM, Greg KH  wrote:
>>> On Wed, Feb 07, 2018 at 11:11:49AM -0500, Blake lee wrote:
 Virtual Machine fails to start when trying to pass through USB PCIe card.

 Virtual Machine setup in libvirt with USB PCie card set to pass through.

 06:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB
 3.0 Host Controller [1912:0014] (rev 03)
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

 Starting the VM causes the oops immediately.

 Actual Results: VM Fails to start
 Expected Results: VM starts and usb devices plugged into the USB card
 are passed through.

 Linux volidesk 4.15.1-acs #1 SMP Fri Feb 2 10:00:52 EST 2018 x86_64 
 GNU/Linux

 This works fine with 4.14.16.
>>>
>>> Any chance you can run 'git bisect' to find the offending patch?
>>>
>>> Any chance you can provide the output of the oops message you get?
>>>
>>> thanks,
>>>
>>> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: VM Fails to Start When Passing Through PCIe Card

[Greg KH]

On Wed, Feb 07, 2018 at 11:11:49AM -0500, Blake lee wrote:
> Virtual Machine fails to start when trying to pass through USB PCIe card.
> 
> Virtual Machine setup in libvirt with USB PCie card set to pass through.
> 
> 06:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB
> 3.0 Host Controller [1912:0014] (rev 03)
> Kernel driver in use: xhci_hcd
> Kernel modules: xhci_pci
> 
> Starting the VM causes the oops immediately.
> 
> Actual Results: VM Fails to start
> Expected Results: VM starts and usb devices plugged into the USB card
> are passed through.
> 
> Linux volidesk 4.15.1-acs #1 SMP Fri Feb 2 10:00:52 EST 2018 x86_64 GNU/Linux
> 
> This works fine with 4.14.16.

Any chance you can run 'git bisect' to find the offending patch?

Any chance you can provide the output of the oops message you get?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

[Rafael J. Wysocki]

On Mon, Feb 5, 2018 at 6:06 PM, Rafael J. Wysocki
 wrote:
> On 2/5/2018 3:14 PM, Bjørn Mork wrote:
>>
>> "Rafael J. Wysocki"  writes:
>>>
>>> On 2/4/2018 9:28 PM, Bjørn Mork wrote:
>>>
 But I do wonder if the attached (completely untested!!) patch makes
 things any better?
>>>
>>> I don't think so, the macro is needed too.
>>
>> Doh! Obviously.  Don't know how I managed to miss that.
>>
>>> I'll queue up a full revert of 662591461c4b9a1e3b.
>>
>> Still with the additional exception for "ec == first_ec"?
>>
>
> No, just a full revert for now.

That doesn't work, because we made some changes on top of this commit.

I'll send a patch to try tomorrow.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> On 05.02.2018 07:08, Rob Herring wrote:
> > On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> >> These bindings allow to describe most known standard USB connectors
> >> and it should be possible to extend it if necessary.
> >> USB connectors, beside USB can be used to route other protocols,
> >> for example UART, Audio, MHL. In such case every device passing data
> >> through the connector should have appropriate graph bindings.
> >>
> >> Signed-off-by: Andrzej Hajda 
> >> ---
> >> v2:
> >> - moved connector type(A,B,C) to compatible string (Rob),
> >> - renamed size property to type (Rob),
> >> - changed type description to be less confusing (Laurent),
> >> - removed vendor specific compatibles (implied by graph port number),
> > How so? More below...
> >
> >> - added requirement of connector being a child of IC (Rob),
> >> - removed max-mode (subtly suggested by Rob, it should be detected anyway
> >>   by USB Controller in runtime, downside is that device is not able to
> >>   report its real capabilities, maybe better would be to make it 
> >> optional(?)),
> >> - assigned port numbers to data buses (Rob).
> >>
> >> Regards
> >> Andrzej
> >>
> >> Signed-off-by: Andrzej Hajda 
> >> ---
> >>  .../bindings/connector/usb-connector.txt   | 48 
> >> ++
> >>  1 file changed, 48 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/connector/usb-connector.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> >> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >> new file mode 100644
> >> index ..02020f5d760a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >> @@ -0,0 +1,48 @@
> >> +USB Connector
> >> +=
> >> +
> >> +USB connector node represents physical USB connector. It should be
> >> +a child of USB interface controller.
> >> +
> >> +Required properties:
> >> +- compatible: describes type of the connector, must be one of:
> >> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> > Nit: one per line.
> >
> >> +
> >> +Optional properties:
> >> +- label: symbolic name for the connector
> >> +- type: size of the connector, should be specified in case of USB-A, USB-B
> >> +  non-standard (large) connector sizes: "mini", "micro"
> >> +
> >> +Required nodes:
> >> +- any data bus to the connector should be modeled using the OF graph 
> >> bindings
> >> +  specified in bindings/graph.txt, unless the bus is between parent node 
> >> and
> >> +  the connector. Since single connector can have multpile data buses 
> >> every bus
> >> +  has assigned OF graph port number as follows:
> >> +0: High Speed (HS), present in all connectors,
> >> +1: Super Speed (SS), present in SS capable connectors,
> >> +2: Sideband use (SBU), present in USB-C,
> >> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
> >> micro-USB
> > This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> > That makes me think the Samsung connector should have its own compatible 
> > string.
> 
> Do you mean, sth like:
>     connector {
>             compatible = "samsung,usb-connector-11pin";
>             label = "micro-USB";
>             ports {
>                     #address-cells = <1>;
>                     #size-cells = <0>;
> 
>                     port@3 {
>                             reg = <3>;
>                             musb_con_mhl_in: endpoint {
>                                     remote-endpoint = <_out>;
>                             };
>                     };
>     };

Yes, basically.

> 
> Or should I add "usb-b-connector" extra compatible and "type" property?

type would be micro? I think type and "usb-b-connector" are fine if this 
is a superset like a USB3 SS micro connector.

> I slightly prefer my approach(less different bindings), but I am also OK
> with the above.

How do you know it is a Samsung connector then? Just because you have 
port 3? I think it is better to be explicit.

> 
> >
> > Can we go ahead and define the video modes of Type-C? Normally, if 2 
> > data streams are mutually exclusive, then they are a single port with 2 
> > endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> > port 3 is always video. We can still know what is mutually exclusive 
> > based on the compatible. 
> 
> I am sorry, I do not understand what you mean. Port 3 is present only in
> 11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.

So video on Type C would be on port 1 (SS), endpoint ? ? That's not 
defined in the binding and I want to define it.

> Here is list of possible ports depending on connector type:
> - USB 2.0: HS
> - 11-pin Samsung micro-USB: HS,MHL
> - USB 3.x type A,B: HS,SS
> - USB-C: HS,SS,SBU
> 
> All ports have separate lines, so they 

[PATCH 3.18 4/9] usbip: Fix potential format overflow in userspace tools

[Shuah Khan]

Upstream commit e5dfa3f902b9 ("usbip: Fix potential format overflow in
userspace tools")

The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.

More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.

This patch fixes these problems by replacing sprintf() with snprintf()
in one place and adding checks for the return value of snprintf().

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/libsrc/usbip_common.c  |  9 -
 tools/usb/usbip/libsrc/usbip_host_driver.c | 27 ++-
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710473de..8000445ff884 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_device *udev, int 
i,
   struct usbip_usb_interface *uinf)
 {
char busid[SYSFS_BUS_ID_SIZE];
+   int size;
struct udev_device *sif;
 
-   sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+   size = snprintf(busid, sizeof(busid), "%s:%d.%d",
+   udev->busid, udev->bConfigurationValue, i);
+   if (size < 0 || (unsigned int)size >= sizeof(busid)) {
+   err("busid length %i >= %lu or < 0", size,
+   (unsigned long)sizeof(busid));
+   return -1;
+   }
 
sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", 
busid);
if (!sif) {
diff --git a/tools/usb/usbip/libsrc/usbip_host_driver.c 
b/tools/usb/usbip/libsrc/usbip_host_driver.c
index bef08d5c44e8..071b9ce99420 100644
--- a/tools/usb/usbip/libsrc/usbip_host_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_host_driver.c
@@ -39,13 +39,19 @@ struct udev *udev_context;
 static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 {
char status_attr_path[SYSFS_PATH_MAX];
+   int size;
int fd;
int length;
char status;
int value = 0;
 
-   snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
-udev->path);
+   size = snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
+   udev->path);
+   if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
+   err("usbip_status path length %i >= %lu or < 0", size,
+   (unsigned long)sizeof(status_attr_path));
+   return -1;
+   }
 
fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -225,6 +231,7 @@ int usbip_host_export_device(struct usbip_exported_device 
*edev, int sockfd)
 {
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+   int size;
char sockfd_buff[30];
int ret;
 
@@ -244,10 +251,20 @@ int usbip_host_export_device(struct usbip_exported_device 
*edev, int sockfd)
}
 
/* only the first interface is true */
-   snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
-edev->udev.path, attr_name);
+   size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+   edev->udev.path, attr_name);
+   if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
+   err("exported device path length %i >= %lu or < 0", size,
+   (unsigned long)sizeof(sockfd_attr_path));
+   return -1;
+   }
 
-   snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
+   err("socket length %i >= %lu or < 0", size,
+   (unsigned long)sizeof(sockfd_buff));
+   return -1;
+   }
 
ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 0/9] Backports for security and critical bug fixes

[Shuah Khan]

As I started backporting security fixes, found a few problems
that prevent tools to build on newer gcc releases, deadlock bug,
and another bug that prevents client from being able to use
imported devices.

This patch series consists of security fixes and fixes to critical
bugs.

Andrew Goodbody (1):
  usb: usbip: Fix possible deadlocks reported by lockdep

Shuah Khan (8):
  usbip: fix stub_rx: get_pipe() to validate endpoint number
  usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
  usbip: prevent vhci_hcd driver from leaking a socket pointer address
  usbip: Fix potential format overflow in userspace tools
  usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit
  usbip: prevent leaking socket pointer address in messages
  usbip: stub: stop printing kernel pointer addresses in messages
  usbip: vhci: stop printing kernel pointer addresses in messages

 drivers/usb/usbip/stub_dev.c   |   3 +-
 drivers/usb/usbip/stub_main.c  |   5 +-
 drivers/usb/usbip/stub_rx.c|  53 +++
 drivers/usb/usbip/stub_tx.c|   4 +-
 drivers/usb/usbip/usbip_common.c   |  15 ++---
 drivers/usb/usbip/usbip_common.h   |   1 +
 drivers/usb/usbip/usbip_event.c|   5 +-
 drivers/usb/usbip/vhci_hcd.c   | 102 +++--
 drivers/usb/usbip/vhci_rx.c|  53 ---
 drivers/usb/usbip/vhci_sysfs.c |  45 +++--
 drivers/usb/usbip/vhci_tx.c|  17 +++--
 tools/usb/usbip/libsrc/usbip_common.c  |   9 ++-
 tools/usb/usbip/libsrc/usbip_host_driver.c |  27 ++--
 tools/usb/usbip/libsrc/vhci_driver.c   |   8 +--
 14 files changed, 205 insertions(+), 142 deletions(-)

-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 1/9] usbip: fix stub_rx: get_pipe() to validate endpoint number

[Shuah Khan]

Upstream commit 635f545a7e8b ("usbip: fix stub_rx: get_pipe() to
validate endpoint number")

get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().

Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.

Reported-by: Secunia Research 
Cc: stable 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_rx.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 00e475c51a12..2e07acda456e 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -347,15 +347,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
 
+   if (epnum < 0 || epnum > 15)
+   goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
-   if (!ep) {
-   dev_err(>interface->dev, "no such endpoint?, %d\n",
-   epnum);
-   BUG();
-   }
+   if (!ep)
+   goto err_ret;
 
epd = >desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -386,9 +386,10 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
return usb_rcvisocpipe(udev, epnum);
}
 
+err_ret:
/* NOT REACHED */
dev_err(>interface->dev, "get pipe, epnum %d\n", epnum);
-   return 0;
+   return -1;
 }
 
 static void masking_bogus_flags(struct urb *urb)
@@ -454,6 +455,9 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
 
+   if (pipe == -1)
+   return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 6/9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

[Shuah Khan]

Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
support")

vhci_hcd clears all the bits port_status bits instead of clearing
just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature:
USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad
state, leaving device unusable by the client. The device is still
attached and however client can't use it.

The problem was fixed as part of larger change to add USB3 Super Speed
support.

This patch isolates the one line fix to clear the USB_PORT_STAT_POWER
from the original patch.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/vhci_hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 2c7bed7b19d6..e480b924a04c 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -279,7 +279,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
case USB_PORT_FEAT_POWER:
usbip_dbg_vhci_rh(
" ClearPortFeature: USB_PORT_FEAT_POWER\n");
-   dum->port_status[rhport] = 0;
+   dum->port_status[rhport] &= ~USB_PORT_STAT_POWER;
dum->resuming = 0;
break;
case USB_PORT_FEAT_C_RESET:
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 7/9] usbip: prevent leaking socket pointer address in messages

[Shuah Khan]

Upstream commit 90120d15f4c3 ("usbip: prevent leaking socket pointer
address in messages")

usbip driver is leaking socket pointer address in messages. Remove
the messages that aren't useful and print sockfd in the ones that
are useful for debugging.

Signed-off-by: Shuah Khan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_dev.c |  3 +--
 drivers/usb/usbip/usbip_common.c | 15 ---
 drivers/usb/usbip/vhci_hcd.c |  2 +-
 3 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index fac20e0434c0..8123a6b2eade 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -163,8 +163,7 @@ static void stub_shutdown_connection(struct usbip_device 
*ud)
 * step 1?
 */
if (ud->tcp_socket) {
-   dev_dbg(>udev->dev, "shutdown tcp_socket %p\n",
-   ud->tcp_socket);
+   dev_dbg(>udev->dev, "shutdown sockfd %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
 
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index 9752b93f754e..1838f1b2c2fa 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -317,18 +317,14 @@ int usbip_recv(struct socket *sock, void *buf, int size)
struct msghdr msg;
struct kvec iov;
int total = 0;
-
/* for blocks of if (usbip_dbg_flag_xmit) */
char *bp = buf;
int osize = size;
 
-   usbip_dbg_xmit("enter\n");
-
-   if (!sock || !buf || !size) {
-   pr_err("invalid arg, sock %p buff %p size %d\n", sock, buf,
-  size);
+   if (!sock || !buf || !size)
return -EINVAL;
-   }
+
+   usbip_dbg_xmit("enter\n");
 
do {
sock->sk->sk_allocation = GFP_NOIO;
@@ -341,11 +337,8 @@ int usbip_recv(struct socket *sock, void *buf, int size)
msg.msg_flags  = MSG_NOSIGNAL;
 
result = kernel_recvmsg(sock, , , 1, size, MSG_WAITALL);
-   if (result <= 0) {
-   pr_debug("receive sock %p buf %p size %u ret %d total 
%d\n",
-sock, buf, size, result, total);
+   if (result <= 0)
goto err;
-   }
 
size -= result;
buf += result;
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index e480b924a04c..a57843e1173f 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -782,7 +782,7 @@ static void vhci_shutdown_connection(struct usbip_device 
*ud)
 
/* need this? see stub_dev.c */
if (ud->tcp_socket) {
-   pr_debug("shutdown tcp_socket %p\n", ud->tcp_socket);
+   pr_debug("shutdown sockfd %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
 
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 5/9] usb: usbip: Fix possible deadlocks reported by lockdep

[Shuah Khan]

From: Andrew Goodbody 

Upstream commit 21619792d1ec ("usb: usbip: Fix possible deadlocks
reported by lockdep")

Change spin_lock calls to spin_lock_irqsave to prevent
attmpted recursive lock taking in interrupt context.

This patch fixes Bug 109351
  https://bugzilla.kernel.org/show_bug.cgi?id=109351

Signed-off-by: Andrew Goodbody 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/usbip_event.c |  5 ++-
 drivers/usb/usbip/vhci_hcd.c| 88 -
 drivers/usb/usbip/vhci_rx.c | 30 --
 drivers/usb/usbip/vhci_sysfs.c  | 19 +
 drivers/usb/usbip/vhci_tx.c | 14 ---
 5 files changed, 91 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/usbip/usbip_event.c b/drivers/usb/usbip/usbip_event.c
index 64933b993d7a..2580a32bcdff 100644
--- a/drivers/usb/usbip/usbip_event.c
+++ b/drivers/usb/usbip/usbip_event.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL_GPL(usbip_event_add);
 int usbip_event_happened(struct usbip_device *ud)
 {
int happened = 0;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (ud->event != 0)
happened = 1;
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
return happened;
 }
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index c02374b6049c..2c7bed7b19d6 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -121,9 +121,11 @@ static void dump_port_status_diff(u32 prev_status, u32 
new_status)
 
 void rh_port_connect(int rhport, enum usb_device_speed speed)
 {
+   unsigned long   flags;
+
usbip_dbg_vhci_rh("rh_port_connect %d\n", rhport);
 
-   spin_lock(_controller->lock);
+   spin_lock_irqsave(_controller->lock, flags);
 
the_controller->port_status[rhport] |= USB_PORT_STAT_CONNECTION
| (1 << USB_PORT_FEAT_C_CONNECTION);
@@ -139,22 +141,24 @@ void rh_port_connect(int rhport, enum usb_device_speed 
speed)
break;
}
 
-   spin_unlock(_controller->lock);
+   spin_unlock_irqrestore(_controller->lock, flags);
 
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
 }
 
 static void rh_port_disconnect(int rhport)
 {
+   unsigned long   flags;
+
usbip_dbg_vhci_rh("rh_port_disconnect %d\n", rhport);
 
-   spin_lock(_controller->lock);
+   spin_lock_irqsave(_controller->lock, flags);
 
the_controller->port_status[rhport] &= ~USB_PORT_STAT_CONNECTION;
the_controller->port_status[rhport] |=
(1 << USB_PORT_FEAT_C_CONNECTION);
 
-   spin_unlock(_controller->lock);
+   spin_unlock_irqrestore(_controller->lock, flags);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
 }
 
@@ -182,13 +186,14 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
int retval;
int rhport;
int changed = 0;
+   unsigned long   flags;
 
retval = DIV_ROUND_UP(VHCI_NPORTS + 1, 8);
memset(buf, 0, retval);
 
vhci = hcd_to_vhci(hcd);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (!HCD_HW_ACCESSIBLE(hcd)) {
usbip_dbg_vhci_rh("hw accessible flag not on?\n");
goto done;
@@ -209,7 +214,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
usb_hcd_resume_root_hub(hcd);
 
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
return changed ? retval : 0;
 }
 
@@ -230,6 +235,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
struct vhci_hcd *dum;
int retval = 0;
int rhport;
+   unsigned long   flags;
 
u32 prev_port_status[VHCI_NPORTS];
 
@@ -248,7 +254,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 
dum = hcd_to_vhci(hcd);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
 
/* store old status and compare now and old later */
if (usbip_dbg_flag_vhci_rh) {
@@ -402,7 +408,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
}
usbip_dbg_vhci_rh(" bye\n");
 
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
return retval;
 }
@@ -425,6 +431,7 @@ static void vhci_tx_urb(struct urb *urb)
 {
struct vhci_device *vdev = get_vdev(urb->dev);
struct vhci_priv *priv;
+   unsigned long flags;
 
if (!vdev) {
pr_err("could not get virtual device");
@@ -437,7 +444,7 @@ static void vhci_tx_urb(struct urb *urb)
return;
}
 
-   spin_lock(>priv_lock);
+   spin_lock_irqsave(>priv_lock, 

[PATCH 3.18 8/9] usbip: stub: stop printing kernel pointer addresses in messages

[Shuah Khan]

Upstream commit 248a22044366 ("usbip: stub: stop printing kernel
pointer addresses in messages")

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_main.c | 5 +++--
 drivers/usb/usbip/stub_rx.c   | 7 ++-
 drivers/usb/usbip/stub_tx.c   | 4 ++--
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index af10f7b131a4..325b4c05acdd 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -252,11 +252,12 @@ void stub_device_cleanup_urbs(struct stub_device *sdev)
struct stub_priv *priv;
struct urb *urb;
 
-   dev_dbg(>udev->dev, "free sdev %p\n", sdev);
+   dev_dbg(>udev->dev, "Stub device cleaning up urbs\n");
 
while ((priv = stub_priv_pop(sdev))) {
urb = priv->urb;
-   dev_dbg(>udev->dev, "free urb %p\n", urb);
+   dev_dbg(>udev->dev, "free urb seqnum %lu\n",
+   priv->seqnum);
usb_kill_urb(urb);
 
kmem_cache_free(stub_priv_cache, priv);
diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index f5533c99cd48..56cacb68040c 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -230,9 +230,6 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev,
if (priv->seqnum != pdu->u.cmd_unlink.seqnum)
continue;
 
-   dev_info(>urb->dev->dev, "unlink urb %p\n",
-priv->urb);
-
/*
 * This matched urb is not completed yet (i.e., be in
 * flight in usb hcd hardware/driver). Now we are
@@ -271,8 +268,8 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev,
ret = usb_unlink_urb(priv->urb);
if (ret != -EINPROGRESS)
dev_err(>urb->dev->dev,
-   "failed to unlink a urb %p, ret %d\n",
-   priv->urb, ret);
+   "failed to unlink a urb # %lu, ret %d\n",
+   priv->seqnum, ret);
 
return 0;
}
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index af858d52608a..f4dd30c56f36 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -201,8 +201,8 @@ static int stub_send_ret_submit(struct stub_device *sdev)
 
/* 1. setup usbip_header */
setup_ret_submit_pdu(_header, urb);
-   usbip_dbg_stub_tx("setup txdata seqnum: %d urb: %p\n",
- pdu_header.base.seqnum, urb);
+   usbip_dbg_stub_tx("setup txdata seqnum: %d\n",
+ pdu_header.base.seqnum);
usbip_header_correct_endian(_header, 1);
 
iov[iovnum].iov_base = _header;
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 2/9] usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input

[Shuah Khan]

Upstream commit c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path
to handle malicious input")

Harden CMD_SUBMIT path to handle malicious input that could trigger
large memory allocations. Add checks to validate transfer_buffer_length
and number_of_packets to protect against bad input requesting for
unbounded memory allocations. Validate early in get_pipe() and return
failure.

Reported-by: Secunia Research 
Cc: stable 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_rx.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 2e07acda456e..f5533c99cd48 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -341,11 +341,13 @@ static struct stub_priv *stub_priv_alloc(struct 
stub_device *sdev,
return priv;
 }
 
-static int get_pipe(struct stub_device *sdev, int epnum, int dir)
+static int get_pipe(struct stub_device *sdev, struct usbip_header *pdu)
 {
struct usb_device *udev = sdev->udev;
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+   int epnum = pdu->base.ep;
+   int dir = pdu->base.direction;
 
if (epnum < 0 || epnum > 15)
goto err_ret;
@@ -358,6 +360,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
goto err_ret;
 
epd = >desc;
+
if (usb_endpoint_xfer_control(epd)) {
if (dir == USBIP_DIR_OUT)
return usb_sndctrlpipe(udev, epnum);
@@ -380,6 +383,27 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
}
 
if (usb_endpoint_xfer_isoc(epd)) {
+   /* validate packet size and number of packets */
+   unsigned int maxp, packets, bytes;
+
+#define USB_EP_MAXP_MULT_SHIFT  11
+#define USB_EP_MAXP_MULT_MASK   (3 << USB_EP_MAXP_MULT_SHIFT)
+#define USB_EP_MAXP_MULT(m) \
+   (((m) & USB_EP_MAXP_MULT_MASK) >> USB_EP_MAXP_MULT_SHIFT)
+
+   maxp = usb_endpoint_maxp(epd);
+   maxp *= (USB_EP_MAXP_MULT(
+   __le16_to_cpu(epd->wMaxPacketSize)) + 1);
+   bytes = pdu->u.cmd_submit.transfer_buffer_length;
+   packets = DIV_ROUND_UP(bytes, maxp);
+
+   if (pdu->u.cmd_submit.number_of_packets < 0 ||
+   pdu->u.cmd_submit.number_of_packets > packets) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: isoc invalid num packets %d\n",
+   pdu->u.cmd_submit.number_of_packets);
+   return -1;
+   }
if (dir == USBIP_DIR_OUT)
return usb_sndisocpipe(udev, epnum);
else
@@ -388,7 +412,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
 
 err_ret:
/* NOT REACHED */
-   dev_err(>interface->dev, "get pipe, epnum %d\n", epnum);
+   dev_err(>udev->dev, "CMD_SUBMIT: invalid epnum %d\n", epnum);
return -1;
 }
 
@@ -453,7 +477,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct stub_priv *priv;
struct usbip_device *ud = >ud;
struct usb_device *udev = sdev->udev;
-   int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+   int pipe = get_pipe(sdev, pdu);
 
if (pipe == -1)
return;
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.18 3/9] usbip: prevent vhci_hcd driver from leaking a socket pointer address

[Shuah Khan]

commit 2f2d0088eb93 ("usbip: prevent vhci_hcd driver from leaking a
socket pointer address")

When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the

/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.

Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from
socket pointer address by looking up /proc/net/{tcp,tcp6}.

As this opens a security hole, the fix replaces socket pointer address
with sockfd.

Reported-by: Secunia Research 
Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/usbip_common.h |  1 +
 drivers/usb/usbip/vhci_sysfs.c   | 26 +++---
 tools/usb/usbip/libsrc/vhci_driver.c |  8 
 3 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index 86b08475c254..f875ccaa55f9 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -261,6 +261,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
 
+   int sockfd;
struct socket *tcp_socket;
 
struct task_struct *tcp_rx;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index 211f43f67ea2..f05f1e0a2baf 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -39,16 +39,20 @@ static ssize_t status_show(struct device *dev, struct 
device_attribute *attr,
 
/*
 * output example:
-* prt sta spd dev socket   local_busid
-* 000 004 000 000 c5a7bb80 1-2.3
-* 001 004 000 000 d8cee980 2-3.4
+* prt  sta spd dev  sockfd local_busid
+*  004 000  03 1-2.3
+* 0001 004 000  04 2-3.4
 *
-* IP address can be retrieved from a socket pointer address by looking
-* up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
-* port number and its peer IP address.
+* Output includes socket fd instead of socket pointer address to
+* avoid leaking kernel memory address in:
+*  /sys/devices/platform/vhci_hcd.0/status and in debug output.
+* The socket pointer address is not used at the moment and it was
+* made visible as a convenient way to find IP address from socket
+* pointer address by looking up /proc/net/{tcp,tcp6}. As this opens
+* a security hole, the change is made to use sockfd instead.
 */
out += sprintf(out,
-  "prt sta spd bus dev socket   local_busid\n");
+  "prt sta spd dev  sockfd local_busid\n");
 
for (i = 0; i < VHCI_NPORTS; i++) {
struct vhci_device *vdev = port_to_vdev(i);
@@ -59,12 +63,11 @@ static ssize_t status_show(struct device *dev, struct 
device_attribute *attr,
if (vdev->ud.status == VDEV_ST_USED) {
out += sprintf(out, "%03u %08x ",
   vdev->speed, vdev->devid);
-   out += sprintf(out, "%16p ", vdev->ud.tcp_socket);
+   out += sprintf(out, "%06u ", vdev->ud.sockfd);
out += sprintf(out, "%s", dev_name(>udev->dev));
 
-   } else {
-   out += sprintf(out, "000 000 000  0-0");
-   }
+   } else
+   out += sprintf(out, "000  00 0-0");
 
out += sprintf(out, "\n");
spin_unlock(>ud.lock);
@@ -223,6 +226,7 @@ static ssize_t store_attach(struct device *dev, struct 
device_attribute *attr,
 
vdev->devid = devid;
vdev->speed = speed;
+   vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
 
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index ad9204773533..1274f326242c 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -55,12 +55,12 @@ static int parse_status(const char *value)
 
while (*c != '\0') {
int port, status, speed, devid;
-   unsigned long socket;
+   int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
 
-   ret = sscanf(c, "%d %d %d %x %lx %31s\n",
+   ret = sscanf(c, "%d %d %d %x %u %31s\n",
, , ,
-   , , lbusid);
+   , , lbusid);
 
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -69,7 +69,7 @@ static int parse_status(const char *value)
 
dbg("port %d status %d speed %d devid 

[PATCH 3.18 9/9] usbip: vhci: stop printing kernel pointer addresses in messages

[Shuah Khan]

Upstream commit 8272d099d05f ("usbip: vhci: stop printing kernel
pointer addresses in messages")

Remove and/or change debug, info. and error messages to not print
kernel pointer addresses.

Signed-off-by: Shuah Khan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/vhci_hcd.c | 10 --
 drivers/usb/usbip/vhci_rx.c  | 23 +++
 drivers/usb/usbip/vhci_tx.c  |  3 ++-
 3 files changed, 13 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index a57843e1173f..869938036248 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -469,9 +469,6 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb 
*urb,
struct vhci_device *vdev;
unsigned long flags;
 
-   usbip_dbg_vhci_hc("enter, usb_hcd %p urb %p mem_flags %d\n",
- hcd, urb, mem_flags);
-
/* patch to usb_sg_init() is in 2.5.60 */
BUG_ON(!urb->transfer_buffer && urb->transfer_buffer_length);
 
@@ -630,8 +627,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb 
*urb, int status)
struct vhci_device *vdev;
unsigned long flags;
 
-   pr_info("dequeue a urb %p\n", urb);
-
spin_lock_irqsave(_controller->lock, flags);
 
priv = urb->hcpriv;
@@ -659,7 +654,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb 
*urb, int status)
/* tcp connection is closed */
spin_lock(>priv_lock);
 
-   pr_info("device %p seems to be disconnected\n", vdev);
list_del(>list);
kfree(priv);
urb->hcpriv = NULL;
@@ -671,8 +665,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb 
*urb, int status)
 * vhci_rx will receive RET_UNLINK and give back the URB.
 * Otherwise, we give back it here.
 */
-   pr_info("gives back urb %p\n", urb);
-
usb_hcd_unlink_urb_from_ep(hcd, urb);
 
spin_unlock_irqrestore(_controller->lock, flags);
@@ -701,8 +693,6 @@ static int vhci_urb_dequeue(struct usb_hcd *hcd, struct urb 
*urb, int status)
 
unlink->unlink_seqnum = priv->seqnum;
 
-   pr_info("device %p seems to be still connected\n", vdev);
-
/* send cmd_unlink and try to cancel the pending URB in the
 * peer */
list_add_tail(>list, >unlink_tx);
diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c
index d656e0edc3d5..323aa7789989 100644
--- a/drivers/usb/usbip/vhci_rx.c
+++ b/drivers/usb/usbip/vhci_rx.c
@@ -37,24 +37,23 @@ struct urb *pickup_urb_and_free_priv(struct vhci_device 
*vdev, __u32 seqnum)
urb = priv->urb;
status = urb->status;
 
-   usbip_dbg_vhci_rx("find urb %p vurb %p seqnum %u\n",
-   urb, priv, seqnum);
+   usbip_dbg_vhci_rx("find urb seqnum %u\n", seqnum);
 
switch (status) {
case -ENOENT:
/* fall through */
case -ECONNRESET:
-   dev_info(>dev->dev,
-"urb %p was unlinked %ssynchronuously.\n", urb,
-status == -ENOENT ? "" : "a");
+   dev_dbg(>dev->dev,
+"urb seq# %u was unlinked %ssynchronuously\n",
+seqnum, status == -ENOENT ? "" : "a");
break;
case -EINPROGRESS:
/* no info output */
break;
default:
-   dev_info(>dev->dev,
-"urb %p may be in a error, status %d\n", urb,
-status);
+   dev_dbg(>dev->dev,
+"urb seq# %u may be in a error, status %d\n",
+seqnum, status);
}
 
list_del(>list);
@@ -79,8 +78,8 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev,
spin_unlock_irqrestore(>priv_lock, flags);
 
if (!urb) {
-   pr_err("cannot find a urb of seqnum %u\n", pdu->base.seqnum);
-   pr_info("max seqnum %d\n",
+   pr_err("cannot find a urb of seqnum %u max seqnum %d\n",
+   pdu->base.seqnum,
atomic_read(_controller->seqnum));
usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
return;
@@ -103,7 +102,7 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev,
if (usbip_dbg_flag_vhci_rx)
usbip_dump_urb(urb);
 
-   usbip_dbg_vhci_rx("now giveback urb %p\n", urb);
+   usbip_dbg_vhci_rx("now giveback urb %u\n", 

[PATCH] Revert "usb: musb: host: don't start next rx urb if current one failed"

[Bin Liu]

This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.

commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one 
failed")
along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
try to solve the issue described in [1], but the latter alone is sufficient,
and the former causes the issue as in [2], so now revert it.

[1] https://marc.info/?l=linux-usb=146173995117456=2
[2] https://marc.info/?l=linux-usb=151689238420622=2

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 394b4ac86161..45ed32c2cba9 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -391,13 +391,7 @@ static void musb_advance_schedule(struct musb *musb, 
struct urb *urb,
}
}
 
-   /*
-* The pipe must be broken if current urb->status is set, so don't
-* start next urb.
-* TODO: to minimize the risk of regression, only check urb->status
-* for RX, until we have a test case to understand the behavior of TX.
-*/
-   if ((!status || !is_in) && qh && qh->is_ready) {
+   if (qh != NULL && qh->is_ready) {
musb_dbg(musb, "... next ep%d %cX urb %p",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: fix enumeration after resume

[Bin Liu]

On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote:
> Hi,
> 
> On Tue, 6 Feb 2018 12:46:05 -0600
> Bin Liu  wrote:
> 
> > Hi,
> > 
> > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote:
> > > On dm3730 there are enumeration problems after resume.
> > > Investigation led to the cause that the MUSB_POWER_SOFTCONN
> > > bit is not set. If it was set before suspend (because it
> > > was enabled via musb_pullup()), it is set in
> > > musb_restore_context() so the pullup is enabled. But then
> > > musb_start() is called which overwrites MUSB_POWER and
> > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> > > enabled and the device is not enumerated.  
> >  
> > Do you see the issue with the v4.15?
> > 
> Yes. Tested without other patches. 
> It was also there in earlier kernels but I had not had motivation enough
> to debug.

Applied to my tree. Thanks.

> So maybe it deserves a CC: Stable

I would prefer it is first tested on each stable tree.

> > > So let's do a subset of what musb_start() does
> > > in the same way as musb_suspend() does it. Platform-specific
> > > stuff it still called as there might be some phy-related stuff
> > > which needs to be enabled.
> > > Also interrupts are enabled, as it was the original idea
> > > of calling musb_start() in musb_resume() according to
> > > Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
> > > enable them on resume")  
> > 
> > The logic in the fix makes sense, and I do see the same problem with
> > AM335x on v4.9 kernel, but it doesn't happen on v4.15. I haven't checked
> > if there is anything after musb_start() which sets MUSB_POWER_SOFTCON
> > bit.

On v4.15, the SESSION bit is set later which sets the SOFTCON bit. I
didn't check how come v4.9 doesn't invoke it though.

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: fix enumeration after resume

[Bin Liu]

On Tue, Feb 06, 2018 at 10:47:25AM -0800, Tony Lindgren wrote:
> * Andreas Kemnade  [180127 08:34]:
> > On dm3730 there are enumeration problems after resume.
> > Investigation led to the cause that the MUSB_POWER_SOFTCONN
> > bit is not set. If it was set before suspend (because it
> > was enabled via musb_pullup()), it is set in
> > musb_restore_context() so the pullup is enabled. But then
> > musb_start() is called which overwrites MUSB_POWER and
> > therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> > enabled and the device is not enumerated.
> 
> I just gave this patch a quick try and things seem to behave
> for me from PM point of view:
> 
> Tested-by: Tony Lindgren 

Thanks for testing it.

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Ludovic Desroches]

On Wed, Feb 07, 2018 at 02:55:35PM +0100, Linus Walleij wrote:
> On Thu, Feb 1, 2018 at 10:34 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> > Include irq.h header since it is needed and was indirectly
> > included through of_gpio.h.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Reviewed-by: Linus Walleij 
> 
> Thank you for doing gpiod conversions. Making the world
> a better place!

Thanks, I wish it would be so easy!

I will send a v2 because I have the same issue that the one pointed by
Andy about the gpiod conversion for the lcd driver.

- udc->vbus_pin = devm_gpiod_get_optional(>dev, "atmel,vbus", GPIOD_IN);
+ udc->vbus_pin = devm_gpiod_get(>dev, "atmel,vbus", GPIOD_IN);
+ if (IS_ERR(udc->vbus_pin))
+   udc->vbus_pin = NULL;

I am not sure if I should prefer devm_gpiod_get_optional or
devm_gpiod_get.

Regards

Ludovic
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci_hcd: kernel 4.15.1 oops on suspend to ram

[Jose Marino]

I applied your debugfs fix commits on top of 4.15.1 and it fixes the 
problem. No more kernel oops on suspend.


Jose

On 02/07/2018 02:28 AM, Mathias Nyman wrote:

On 06.02.2018 20:07, Jose Marino wrote:
I'm running archlinux on a Dell XPS15 9550 and I connect it to a TB16 
thunderbolt dock. Connected to the dock I have a 4k external display 
and a USB logitech transmitter for my wireless keyboard and mouse.


The module 'xhci_pci' is automatically unloaded/reloaded on 
suspend/resume to make the TB16 dock work properly across 
suspend/resume cycles.


Yesterday, I updated my kernel from 4.14.16 to 4.15.1 and now I get a 
kernel oops on suspend. I can replicate the oops every time: boot 
computer, connect to thunderbolt dock, suspend.
I managed to get some logs of the kernel oops from EFI pstore. Find 
attached with this email.


Jose

Zhengjun just wrote a patchseries for fixing 4.15 xhci debugfs issues

I  added debugfs-fixes branch with those patches on top of 4.15.
Do they work for you?

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git debugfs-fixes

https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=debugfs-fixes 



I still need to run those patches through some internal testing before 
pushing them out,

but I'm interested in knowing if they solve your NULL pointer dereference

Thanks
-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

VM Fails to Start When Passing Through PCIe Card

[Blake lee]

Virtual Machine fails to start when trying to pass through USB PCIe card.

Virtual Machine setup in libvirt with USB PCie card set to pass through.

06:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB
3.0 Host Controller [1912:0014] (rev 03)
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

Starting the VM causes the oops immediately.

Actual Results: VM Fails to start
Expected Results: VM starts and usb devices plugged into the USB card
are passed through.

Linux volidesk 4.15.1-acs #1 SMP Fri Feb 2 10:00:52 EST 2018 x86_64 GNU/Linux

This works fine with 4.14.16.

output of the kernel oops:
https://pastebin.com/RDN6Xaqw

Libvirt Configuration
https://pastebin.com/UbitetE6


GRUB_CMDLINE_LINUX="pcie_acs_override=downstream intel_iommu=on
rd.luks.options=discard"

Kernel is vanilla 4.15.1 with the acs override patch. Also did not
work with 4.15. Has worked on all previous 4.x.x kernels.

Here is a pastebin of the acs patch. It's the only patch I'm using on
the vanilla kernel
https://pastebin.com/4gbjTG5Y

v/r
Blake Lee
lee.blak...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

Oliver/Greg,
sorry to say but for my custom board it's difficult to flash 4.14 or
4.15. I are not sure that it will boot or not on my platform.
But Still i will try to do that and in parallel will try to flash on
Beagle bone.And will try.

 I used Lecroy today following are some observation..

working case :
for every try of ready_capacity_16 (total 3), there are bulk
transfer(OUT and IN) and status for read_capacity_16 is  "GOOD"

non-working case:
for first try of ready_capacity_16 there is bulk OUT but no IN
transfer , status for read_capacity_16 is "MISSING"
...seems that's that is the case we are receiving the
blk_rq_timed_out_timer() and eventually uas_eh_device_reset_handler()
I could not find why the bulk transfer could not  complete and causing
timer to expire.


Also  adding some msleep(100) before calling sd_read_capacity(), many
times i could not see the issue.

I don't know how to share Lecroy logs here. I can share the logs.


On Tue, Feb 6, 2018 at 3:32 PM, Oliver Neukum  wrote:
> Am Montag, den 05.02.2018, 23:46 +0530 schrieb Tushar Nimkar:
>> Greg,
>>
>> I have cherry-picked 9 patches as follows.
>
> Those won't do you any good. Please test
>
> a) with 4.14 or 4.15
> b) test on another host
>
> And tell me what read_capacity_16() does at USB2.0 speeds
>
> We need to determine whether error handling just works better
> at lower speed or high speed triggers the error. And with
> a current kernel if possible at all.
>
> Regards
> Oliver
>



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Menion]

In which kernel version this commit endup?
The unusual device will be downgraded to BOT mode?

2018-02-07 15:52 GMT+01:00 Tushar Nimkar :
> JMS567 is already reported and under "unusual_devs.h"
> correct me if wrong.
>
> commit ID :d92146222c96c22b45486961be642b1ba1c4129c
>
> On Wed, Feb 7, 2018 at 8:09 PM, Menion  wrote:
>> This is not fully true
>> Multibay enclosure may have problem, see my thread "uas failing on
>> multiple disk access on a jmicron JMS567 bridge"
>>
>> 2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
>>> Thanks Adrian and Greg.
>>>
>>> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH  wrote:
 On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
> Can anyone help me in selecting UASP/UAS device ?
> Any link/ model no. will be helpful.
> I could see unusual_uas.h has many devices which are not behaving well
> so don't want to take risk in selecting.

 The majority work just fine, I've bought lots of them and they all work
 with no issues at all.  Look for good reviews on sites like amazon
 saying that the enclosure works on Linux, and you should be fine.

 good luck!

 greg k-h
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Tushar R Nimkar
>>> Mob No : +91-9052258800
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards,
> Tushar R Nimkar
> Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Greg KH]

On Wed, Feb 07, 2018 at 03:39:33PM +0100, Menion wrote:
> This is not fully true

There are always going to be exceptions, that's why we have a quirk
list.  It's easier to list the small handful of "broken" devices, than
it is to list the "working" devices :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Tushar Nimkar]

JMS567 is already reported and under "unusual_devs.h"
correct me if wrong.

commit ID :d92146222c96c22b45486961be642b1ba1c4129c

On Wed, Feb 7, 2018 at 8:09 PM, Menion  wrote:
> This is not fully true
> Multibay enclosure may have problem, see my thread "uas failing on
> multiple disk access on a jmicron JMS567 bridge"
>
> 2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
>> Thanks Adrian and Greg.
>>
>> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH  wrote:
>>> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
 Can anyone help me in selecting UASP/UAS device ?
 Any link/ model no. will be helpful.
 I could see unusual_uas.h has many devices which are not behaving well
 so don't want to take risk in selecting.
>>>
>>> The majority work just fine, I've bought lots of them and they all work
>>> with no issues at all.  Look for good reviews on sites like amazon
>>> saying that the enclosure works on Linux, and you should be fine.
>>>
>>> good luck!
>>>
>>> greg k-h
>>
>>
>>
>> --
>> Best Regards,
>> Tushar R Nimkar
>> Mob No : +91-9052258800
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Menion]

This is not fully true
Multibay enclosure may have problem, see my thread "uas failing on
multiple disk access on a jmicron JMS567 bridge"

2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
> Thanks Adrian and Greg.
>
> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH  wrote:
>> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>>> Can anyone help me in selecting UASP/UAS device ?
>>> Any link/ model no. will be helpful.
>>> I could see unusual_uas.h has many devices which are not behaving well
>>> so don't want to take risk in selecting.
>>
>> The majority work just fine, I've bought lots of them and they all work
>> with no issues at all.  Look for good reviews on sites like amazon
>> saying that the enclosure works on Linux, and you should be fine.
>>
>> good luck!
>>
>> greg k-h
>
>
>
> --
> Best Regards,
> Tushar R Nimkar
> Mob No : +91-9052258800
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Tushar Nimkar]

Thanks Adrian and Greg.

On Wed, Feb 7, 2018 at 7:59 PM, Greg KH  wrote:
> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>> Can anyone help me in selecting UASP/UAS device ?
>> Any link/ model no. will be helpful.
>> I could see unusual_uas.h has many devices which are not behaving well
>> so don't want to take risk in selecting.
>
> The majority work just fine, I've bought lots of them and they all work
> with no issues at all.  Look for good reviews on sites like amazon
> saying that the enclosure works on Linux, and you should be fine.
>
> good luck!
>
> greg k-h



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

[Greg KH]

On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
> Can anyone help me in selecting UASP/UAS device ?
> Any link/ model no. will be helpful.
> I could see unusual_uas.h has many devices which are not behaving well
> so don't want to take risk in selecting.

The majority work just fine, I've bought lots of them and they all work
with no issues at all.  Look for good reviews on sites like amazon
saying that the enclosure works on Linux, and you should be fine.

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: High CPU load produced by USB (DW2)

[gregkh]

On Wed, Feb 07, 2018 at 10:48:57AM +0100, Mirza Krak wrote:
> Hi.
> 
> I initially started a thread on a different mailing list [1], and you
> can take look there for some additional background.
> 
> I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
> board) which uses the DW2 USB core. I have noticed that when
> connecting a USB device there is unreasonable high CPU load produced
> by the USB interrupts.

That's a normal problem with that kind of hardware.  I've seen devices
with that type of USB core take a 30% cpu usage just when you plug a USB
keyboard into the device.

There's not much the kernel can do about horrible hardware, sorry, go
complain to the device manufacturer :(

> Here is one example with a MIDI keyboard connected on USB (not really
> doing anything on it)
> 
>79 2 root SW   0   0%  19% [irq/45-dwc2_hso]
>78 2 root SW   0   0%  11% [irq/45-ff54]

It doesn't matter if anything is happening on the device, USB goes and
polls the device all the time, that's just the way that the protocol
works.  With hardware like this, that polling is done by the kernel
driver/CPU and does not have offload capability to the USB controller to
handle this type of housekeeping.  Because of that, you see tons of CPU
interrupts and a high load.

Again, not much we can do about that, sorry :(

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors

[Linus Walleij]

On Thu, Feb 1, 2018 at 10:34 AM, Ludovic Desroches
 wrote:

> Use GPIO descriptors instead of relying on the old method.
> Include irq.h header since it is needed and was indirectly
> included through of_gpio.h.
>
> Signed-off-by: Ludovic Desroches 

Reviewed-by: Linus Walleij 

Thank you for doing gpiod conversions. Making the world
a better place!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WARN: Success on ctrl setup TRB without IOC set??

[Mathias Nyman]

On 07.02.2018 11:45, Peter Chen wrote:

Hi Mathias,

I am implementing USB2 EHSET SINGLE_STEP_SET_FEATURE Test for XHCI port,
(see ehset_single_step_set_feature for EHCI), it needs to set IOC
for setup packet, and software waits 15 seconds before DATA + STATUS stage.
After porting such design for XHCI, it triggers above warning, and
returns -ESHUTDOWN for URB. Any reasons why we don't allow completion
interrupt for SETUP stage? Thanks.



Current xhci driver control transfer implementation doesn't support
queuing a control transfer in parts. we set the IOC only for the status
stage, and we always queue a status stage (and possibly data stage) 
automatically
when queuing a control transfer URB.

If we get a success event for the SETUP stage the driver will finish the TD and
return the whole URB.

For testing  purposes you would need to make sure we don't call finish_td() for
a success event at the SETUP stage, something like this (untested):

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c5cbc68..f6d005e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2014,12 +2014,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
 
switch (trb_comp_code) {

case COMP_SUCCESS:
-   if (trb_type != TRB_STATUS) {
-   xhci_warn(xhci, "WARN: Success on ctrl %s TRB without IOC 
set?\n",
- (trb_type == TRB_DATA) ? "data" : "setup");
-   *status = -ESHUTDOWN;
-   break;
-   }
+   if (trb_type == TRB_SETUP)
+   return 0;
*status = 0;
break;
case COMP_SHORT_PACKET:

Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Should debugfs be world-readable?

[Felipe Balbi]

Hi,

Greg Kroah-Hartman  writes:
> On Wed, Feb 07, 2018 at 01:41:27PM +0200, Felipe Balbi wrote:
>> 
>> Hi guys,
>> 
>> I've been thinking about this for a while now. Should we allow debugfs
>> files be world-readable?
>
> By default, debugfs is not mounted world-readable, so no matter what the
> permissions are on the files, "normal" users can't access them.
>
> See commit 82aceae4f0d4 ("debugfs: more tightly restrict default mount mode")
> that was in 3.7 for the last "tightening up" of the permissions on the
> filesystems.

Indeed :-) Thanks for that.

> Does your distro override those values?

No, apparently it doesn't :-) there should be no issues then.

-- 
balbi


signature.asc
Description: PGP signature

Re: Should debugfs be world-readable?

[Greg Kroah-Hartman]

On Wed, Feb 07, 2018 at 01:41:27PM +0200, Felipe Balbi wrote:
> 
> Hi guys,
> 
> I've been thinking about this for a while now. Should we allow debugfs
> files be world-readable?

By default, debugfs is not mounted world-readable, so no matter what the
permissions are on the files, "normal" users can't access them.

See commit 82aceae4f0d4 ("debugfs: more tightly restrict default mount mode")
that was in 3.7 for the last "tightening up" of the permissions on the
filesystems.

Does your distro override those values?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Should debugfs be world-readable?

[Felipe Balbi]

Hi guys,

I've been thinking about this for a while now. Should we allow debugfs
files be world-readable?

Many of these files expose addresses to kernel data. For example dwc3
dumps out the TRB ring of every endpoint:

# cat dwc3.37.auto/ep1in/trb_ring 
buffer_addr,size,type,ioc,isp_imi,csp,chn,lst,hwo
,0,UNKNOWN,0,0,0,0,0,0   ED
,0,UNKNOWN,0,0,0,0,0,0 
,0,UNKNOWN,0,0,0,0,0,0 
,0,UNKNOWN,0,0,0,0,0,0 
,0,UNKNOWN,0,0,0,0,0,0 

[...]

The first field there will be populated with actual addresses once a
gadget driver is loaded and enumerated. Similarly, xhci exposes its own
TRB ring which will show DMA addresses of every TRB:

static void xhci_ring_dump_segment(struct seq_file *s,
   struct xhci_segment *seg)
{
int i;
dma_addr_t  dma;
union xhci_trb  *trb;

for (i = 0; i < TRBS_PER_SEGMENT; i++) {
trb = >trbs[i];
dma = seg->dma + i * sizeof(*trb);
seq_printf(s, "%pad: %s\n", ,
   xhci_decode_trb(trb->generic.field[0],
   trb->generic.field[1],
   trb->generic.field[2],
   trb->generic.field[3]));
}
}

x86/pat_memtype_list also has more addresses. But that's readable only
by root.

So, should we change xhci and dwc3 so that files exposing addresses are
readable by root only? Or do we just convert these files to print with
%pK?

What do you think is the best approach here?

-- 
balbi


signature.asc
Description: PGP signature

High CPU load produced by USB (DW2)

[Mirza Krak]

Hi.

I initially started a thread on a different mailing list [1], and you
can take look there for some additional background.

I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
board) which uses the DW2 USB core. I have noticed that when
connecting a USB device there is unreasonable high CPU load produced
by the USB interrupts.

Here is one example with a MIDI keyboard connected on USB (not really
doing anything on it)

   79 2 root SW   0   0%  19% [irq/45-dwc2_hso]
   78 2 root SW   0   0%  11% [irq/45-ff54]

Can also see that there is a "HIGH" interrupt count

root@esp5-d1:~# watch cat /proc/interrupts | grep usb
 45:   43681938  0  0  0 GIC-0  57 Level
  ff54.usb, dwc2_hsotg:usb1
 46:  0  0  0  0 GIC-0  55 Level
  ff58.usb, ff58.usb, dwc2_hsotg:usb2
 45:   43829473  0  0  0 GIC-0  57 Level
  ff54.usb, dwc2_hsotg:usb1
 46:  0  0  0  0 GIC-0  55 Level
  ff58.usb, ff58.usb, dwc2_hsotg:usb2
 45:   43972333  0  0  0 GIC-0  57 Level
  ff54.usb, dwc2_hsotg:usb1
 46:  0  0  0  0 GIC-0  55 Level
  ff58.usb, ff58.usb, dwc2_hsotg:usb2
 45:   44118769  0  0  0 GIC-0  57 Level
  ff54.usb, dwc2_hsotg:usb1
 46:  0  0  0  0 GIC-0  55 Level
  ff58.usb, ff58.usb, dwc2_hsotg:usb2
 45:   44267876  0  0  0 GIC-0  57 Level
  ff54.usb, dwc2_hsotg:usb1
 46:  0  0  0  0 GIC-0  55 Level
  ff58.usb, ff58.usb, dwc2_hsotg:usb2

Again not really doing anything with the device, it is just connected.
I have also tested with server different devices with same result (BT
and WLAN).

The CPU load is exposed when I add "threadirqs" to kernel arguments,
otherwise it does not seem that it accounted for (not see in "top")
but the number of interrupts is still high.

Any thoughts on this? Please let me know if there is additional
information that I can provide to help debug this.


[1]. https://www.spinics.net/lists/linux-rt-users/msg18341.html

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARN: Success on ctrl setup TRB without IOC set??

[Peter Chen]

Hi Mathias,

I am implementing USB2 EHSET SINGLE_STEP_SET_FEATURE Test for XHCI port,
(see ehset_single_step_set_feature for EHCI), it needs to set IOC
for setup packet, and software waits 15 seconds before DATA + STATUS stage.
After porting such design for XHCI, it triggers above warning, and
returns -ESHUTDOWN for URB. Any reasons why we don't allow completion
interrupt for SETUP stage? Thanks.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB gadget : generic functionfs function has no os_desc while rndis function has, why?

[Krzysztof Opasiak]

On 02/07/2018 08:25 AM, Jun Sun wrote:

Thanks, Krysztof.

I'm trying to follow your example and maybe to massage it into my need.

One quick question -

In your example, you set vendor code to be 0xBC.  Is this code of any
significance?  What values should I use?

b_vendor_code = 0xBC,


Well... according to "spec"[1]:

"bMS_VendorCode is used to retrieve the associated feature descriptors. 
The vendor defines the format of this field. For further details, see 
“OS Feature Descriptors” later in this paper."


USB complete[2] elaborates this pretty good. But to be totally honest I 
took this value from 3.


So from your perspective this could be any value other than 0;)

Footnotes:
1 - 
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-interface-model-supplement


2 - 
https://books.google.pl/books?id=pkefBgAAQBAJ=PA347=PA347=bMS_VendorCode+rndis=bl=6_hwlTDvwy=WmjSiXX9qvWF5aLBxa8M7xYvDNM=pl=X=0ahUKEwj1kcXzvJPZAhVK16QKHeVuAOMQ6AEIRDAE#v=onepage=bMS_VendorCode%20rndis=false


3 - http://doc.hcc-embedded.com/download/attachments/27590911/HCC RNDIS 
Device Class Driver Windows Automatic Installation Guide 
v1.10.pdf?version=1=1507279811000=v2


Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci_hcd: kernel 4.15.1 oops on suspend to ram

[Mathias Nyman]

On 06.02.2018 20:07, Jose Marino wrote:

I'm running archlinux on a Dell XPS15 9550 and I connect it to a TB16 
thunderbolt dock. Connected to the dock I have a 4k external display and a USB 
logitech transmitter for my wireless keyboard and mouse.

The module 'xhci_pci' is automatically unloaded/reloaded on suspend/resume to 
make the TB16 dock work properly across suspend/resume cycles.

Yesterday, I updated my kernel from 4.14.16 to 4.15.1 and now I get a kernel 
oops on suspend. I can replicate the oops every time: boot computer, connect to 
thunderbolt dock, suspend.
I managed to get some logs of the kernel oops from EFI pstore. Find attached 
with this email.

Jose

Zhengjun just wrote a patchseries for fixing 4.15 xhci debugfs issues

I  added debugfs-fixes branch with those patches on top of 4.15.
Do they work for you?

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git debugfs-fixes

https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=debugfs-fixes

I still need to run those patches through some internal testing before pushing 
them out,
but I'm interested in knowing if they solve your NULL pointer dereference

Thanks
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: power management problems in ehci-omap

[Roger Quadros]

Hi,

On 06/02/18 20:40, Andreas Kemnade wrote:
> On Tue, 6 Feb 2018 10:16:23 -0800
> Tony Lindgren  wrote:
> 
>> * Andreas Kemnade  [180206 18:04]:
>>> On Tue, 6 Feb 2018 09:17:37 -0800
>>> Tony Lindgren  wrote:  
 uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
 for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
 done
   
>>>
>>> hmm, this looks a bit like runtime suspend.  
>>
>> Not only that, it enables wakeup for UART also for suspend :)
>>
> We are using the rtc for wakeup and measure discharge of battery
> for a time frame of about 300 seconds.
> 
>> That is if your dts has it configured with interrupts-extended
>> for the console UART like omap3-beagle-xm.dts has for example.
>> Seems like the gta04 dts don't have these.. And you also want
>> to have chosen with stdout-path =  or whatever the debug
>> UART is for earlycon to work.
>>
>>> I mean suspend aka echo mem >/sys/power/state
>>>   
 echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode  
>>
>> And the above will enable SoC and PMIC off modes, which will also
>> take the suspend power to some much much lower value :) You need
>> to configure the PMIC too depending if the oscillator can be turned
>> off, in that case set "ti,twl4030-power-idle-osc-off". That too
>> seems to be missing in gta04 dts files..
>>
> It was in our tree. It can be enabled for the gta04a5. We have even done
> that. But then suspend while charging breaks. I have no idea how to do a
> proper if-not-charging-power-idle-osc-off patch... 
> 
> Yes there are other places where we can optimize suspend current. But
> lets first find out why ehci-omap seems to cause trouble here.
> So we are looking for around 15mA of additional suspend current when the
> module is loaded. 
> Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when
> going to suspend? I do not see code how to do it. I guess that is the
> reason.
> 
> BTW:
> root@letux:~# cat 
> /sys/bus/platform/devices/48064800.ehci/power/runtime_status 
> active


PM handling is not yet there in the ehci-omap driver.

> static struct platform_driver ehci_hcd_omap_driver = {
> .probe  = ehci_hcd_omap_probe,
> .remove = ehci_hcd_omap_remove,
> .shutdown   = usb_hcd_platform_shutdown,
> /*.suspend  = ehci_hcd_omap_suspend, */
> /*.resume   = ehci_hcd_omap_resume, */
> .driver = {
> .name   = hcd_name,
> .of_match_table = omap_ehci_dt_ids,
> }
> };

There is also some co-relation with the parent driver
drivers/mfd/omap-usb-host.c

Getting low power on system suspend should be easy as we most probably don't
need wakeup to work in this case. This should fix the increased power during
system suspend.

To fix active power consumption we need to implement runtime PM.
However, for runtime suspend case we do need remote-wakeup to work else we
won't be able to detect any new USB devices after the host runtime suspends.
For this we need to remux one of the PHY lines into a GPIO to capture the wake 
event.
This is where the generic wakeirq support comes in.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] uas: regression preventing some drives from being used

[Oliver Neukum]

Am Dienstag, den 06.02.2018, 23:13 +0100 schrieb Cyril Roelandt:
> Hi,
> 
> I use two hard drives in an enclosure connected to my PC using UAS. The
> enclosure is a JMicron JMS56x (152d:0562); the drives are a Fujitsu MHZ2160BH
> G2 (2"5, 160GB) and a Western Digital EFRX-68N32N0 (3"5, 4TB).
> 
> Using a USB2 port, I can see both drives as expected. I used to be able to use
> both drives using a USB3 port (and UAS) in Linux 4.11 and 4.12, but I am
> experiencing a bug with Linux 4.14.13.

Hi,

obvious question, can you bisect it? It looks like a low level issue. 
> 
> When I plug the USB cable, I can see the following output in dmesg:
> 
> [Tue Feb  6 22:17:49 2018] usb 4-2: new SuperSpeed USB device number 10 using 
> xhci_hcd
> [Tue Feb  6 22:17:49 2018] usb 4-2: New USB device found, idVendor=152d, 
> idProduct=0562
> [Tue Feb  6 22:17:49 2018] usb 4-2: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=5
> [Tue Feb  6 22:17:49 2018] usb 4-2: Product: JMS56x Series
> [Tue Feb  6 22:17:49 2018] usb 4-2: Manufacturer: JMicron
> [Tue Feb  6 22:17:49 2018] usb 4-2: SerialNumber: RANDOM__8A4D7F833EEF
> [Tue Feb  6 22:17:49 2018] scsi host6: uas
> [Tue Feb  6 22:17:50 2018] scsi 6:0:0:0: Direct-Access FUJITSU  MHZ2160BH 
> G2 0104 PQ: 0 ANSI: 6
> [Tue Feb  6 22:17:50 2018] scsi 6:0:0:1: Direct-Access WDC WD40 
> EFRX-68N32N0 0104 PQ: 0 ANSI: 6
> [Tue Feb  6 22:17:50 2018] sd 6:0:0:0: Attached scsi generic sg2 type 0
> [Tue Feb  6 22:17:50 2018] sd 6:0:0:1: Attached scsi generic sg3 type 0
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:0: [sdb] 312581808 512-byte logical 
> blocks: (160 GB/149 GiB)
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:1: [sdc] 7814037168 512-byte logical 
> blocks: (4.00 TB/3.64 TiB)
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:0: [sdb] Write Protect is off
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:0: [sdb] Mode Sense: 67 00 10 08
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:1: [sdc] Write Protect is off
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:1: [sdc] Mode Sense: 67 00 10 08
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:0: [sdb] Write cache: enabled, read 
> cache: enabled, supports DPO and FUA
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:1: [sdc] Write cache: enabled, read 
> cache: enabled, supports DPO and FUA
> [Tue Feb  6 22:17:57 2018]  sdb: sdb1
> [Tue Feb  6 22:17:57 2018] sd 6:0:0:0: [sdb] Attached SCSI disk
> [Tue Feb  6 22:18:27 2018] sd 6:0:0:1: tag#1 uas_eh_abort_handler 0 uas-tag 2 
> inflight: IN 
> [Tue Feb  6 22:18:27 2018] sd 6:0:0:1: tag#1 CDB: Inquiry 12 01 00 00 40 00
> [Tue Feb  6 22:18:27 2018] scsi host6: uas_eh_device_reset_handler start
> [Tue Feb  6 22:18:28 2018] usb 4-2: reset SuperSpeed USB device number 10 
> using xhci_hcd

Did you see this line with earlier kernels?

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html