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: <e2faf901-84de-41ad-804d-6c86bc304ef1@rowland.harvard.edu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ