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]

Message-ID: <e8e4ac26-9168-452c-80bc-f32904808cc9@rowland.harvard.edu>
Date:   Thu, 30 Nov 2023 13:13:28 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org, oneukum@...e.com, pabeni@...hat.com
Subject: Re: [PATCH] net: usb: ax88179_178a: avoid failed operations when
 device is disconnected

On Thu, Nov 30, 2023 at 06:25:21PM +0100, Jose Ignacio Tornos Martinez wrote:
> Hi Alan,
> 
> Thank you again for you comments.
> 
> > What are these unnecessary operations?
> Sorry if I was not clear, I was referring to the reading and writing 
> operations that are commanded within stop and unbind driver functions.
> This operations are necessary if we unbind to get the device stopped in
> a known state but if the device is detached, they are failing and imho
> they are not necessary. That is the reason why I was trying to detect 
> when the device is really disconnected, to allow sending commands only
> if the device was still connected. 
> 
> > 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.
> Ok, understood, very helpful clarification.
> In any case, I was referring to the internal operations during stop and
> unbind. And if any failed operations are commanded before and after
> disconnection (if any), try to detect with the warning to be sure if there
> is any problem.
> 
> I have checked that other drivers are using USB_STATE_NOTATTACHED to check
> and confirm the device disconnection. And I am trying to analyze other 
> drivers to check if this can be done in another way. 
> If I use -ENODEV as Oliver suggested, I think I wouldn't know if the device
> is disconnected previous to any operation. But maybe this is the way.

I see.  Your approach isn't all that bad.

Another possibility would be to have the unbind routine set a flag in 
the private data structure, and then make the ax88179_write_cmd() and 
ax88179_read_cmd() routines avoid printing error messages if the flag is 
set.  Or don't bother with the flag, and simply make the routines skip 
printing an error message if a transfer fails with error code -ENODEV.

Alan Stern