linux-kernel - Re: [PATCH] net: usb: ax88179_178a: avoid failed operations when device is disconnected

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, 30 Nov 2023 10:50:08 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
Cc:     oneukum@...e.com, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        pabeni@...hat.com
Subject: Re: [PATCH] net: usb: ax88179_178a: avoid failed operations when
 device is disconnected

On Thu, Nov 30, 2023 at 09:41:36AM +0100, Jose Ignacio Tornos Martinez wrote:
> Hi Oliver,
> 
> > I am sorry, but this is a layering violation. You are looking
> > at an internal state of the USB layer to surpress logging
> > -ENODEV. If you think these messages should go away, filter
> > for ENODEV where they are generated.
> Thank you for your comments and suggestion.
> My intention was also to avoid unnecessary and failed operations 
> if disconnection was detected.

What are these unnecessary operations?

> Ok, let me research more and do better.
> 
> Hi Alan,
> 
> > In addition, you should be more careful about the distinction between 
> > "unbound" and "disconnected".  It's possible for the driver to be 
> > unbound from the device even while the device is still plugged in.  In 
> > this situation, submitting URBs will fail with an error even though the 
> > device state isn't USB_STATE_NOTATTACHED.
> Thank you for you comments.
> I also tested "unbound" and stop and unbind operations were correctly 
> executed. I just wanted to avoid the issues during disconnection, if other 
> operations are commanded later I think it is better to warn.

In general, drivers should treat "unbind" the same as "disconnect" (in 
both cases, the ->disconnect() routine is called).  If a driver tries to 
send commands to the device while the disconnect routine is running, it 
should expect that they might fail and not generate an error message if 
they do.

(Also, note that the USB core will allow a driver to send commands to 
the device during unbind only if the .soft_unbind flag is set in the 
usb_driver structure.)

And in any case, a driver should _never_ try to communicate with the 
device after the disconnect routine has returned.

Alan Stern