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]
Message-ID: <3c18614f-eb77-4eff-be1d-068cde655b0a@quicinc.com>
Date:   Wed, 27 Sep 2023 14:17:14 +0530
From:   Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Alan Stern <stern@...land.harvard.edu>,
        Francesco Dolcini <francesco.dolcini@...adex.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        Ivan Orlov <ivan.orlov0322@...il.com>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_ppratap@...cinc.com>, <quic_wcheng@...cinc.com>,
        <quic_jackp@...cinc.com>
Subject: Re: [PATCH v5] usb: gadget: udc: Handle gadget_connect failure during
 bind operation



On 9/27/2023 1:46 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 27, 2023 at 01:00:27PM +0530, Krishna Kurapati wrote:
>> In the event gadget_connect call (which invokes pullup) fails,
>> propagate the error to udc bind operation which in turn sends the
>> error to configfs. The userspace can then retry enumeration if
>> it chooses to.
> 
> Will this break userspace that is not expecting error codes to be
> returned?  What userspace code will now be modified to handle this?
> Where is that work happening?
> 
> thanks,

Hi Greg,

  This only handles cases where the pullup failed but the error code 
wasn't returned to configfs_udc_store approrpiately. In userspace when 
we do the following:

echo "UDC NAME" > /usb_gadget/<>/UDC

in the issue I was facing, the core soft reset was failing and we return 
-110 from dwc3/core.c to udc's bind_to_driver call, but it is not 
checked any where today and we return 0 to udc_store in configfs. The 
userspace assumes the UDC write went through (and enum happened) but it 
actually doesn't. If we propagate the -ETIMEDOUT coming from dwc3-core 
all the way to configfs_udc_store, it will reach userspace as well 
indicating that the echo command was not successful which then the user 
can choose to retry or not. On Android devices, I saw userspace retry 
happening when we propagate dwc3-core error to userspace. So nothing in 
userspace breaks. It can stay as it but this time, the echo in userspace 
will fail if pullup fails for some reason.

Regards,
Krishna,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ