2020-02-26 17:51:58

by Eugeniu Rosca

[permalink] [raw]
Subject: [PATCH v3 1/3] usb: core: hub: fix unhandled return by employing a void function

Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET):

*** CID 1458999: Error handling issues (CHECKED_RETURN)
/drivers/usb/core/hub.c: 1869 in hub_probe()
1863
1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
1865 hub->quirk_check_port_auto_suspend = 1;
1866
1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) {
1868 hub->quirk_disable_autosuspend = 1;
>>> CID 1458999: Error handling issues (CHECKED_RETURN)
>>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times).
1869 usb_autopm_get_interface(intf);
1870 }
1871
1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
1873 return 0;
1874

Rather than checking the return value of 'usb_autopm_get_interface()',
switch to the usb_autopm_get_interface_no_resume() API, as per:

On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote:
------ 8< ------
> This change (i.e. 'ret = usb_autopm_get_interface') is not necessary,
> because the resume operation cannot fail at this point (interfaces
> are always powered-up during probe). A better solution would be to
> call usb_autopm_get_interface_no_resume() instead.
------ 8< ------

Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
Cc: Hardik Gajjar <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected] # v4.14+
Reported-by: [email protected]
Suggested-by: Alan Stern <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
---
v3:
- Make the summary line more clear
- s/autpm/autopm/ in patch description
- Cc <stable> with v4.14+ since v4.14.x is the earliest stable kernel
which accepted commit 1208f9e1d758c9 ("USB: hub: Fix the broken
detection of USB3 device in SMSC hub")

v2:
- [Alan Stern] Use usb_autopm_get_interface_no_resume() instead of
usb_autopm_get_interface()
- Augment commit description to provide background
- Link: https://lore.kernel.org/lkml/[email protected]

v1:
- Link: https://lore.kernel.org/lkml/[email protected]
---
drivers/usb/core/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1d212f82c69b..1105983b5c1c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1866,7 +1866,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)

if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) {
hub->quirk_disable_autosuspend = 1;
- usb_autopm_get_interface(intf);
+ usb_autopm_get_interface_no_resume(intf);
}

if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
--
2.25.1


2020-02-26 17:53:26

by Eugeniu Rosca

[permalink] [raw]
Subject: [PATCH v3 2/3] usb: core: hub: do error out if usb_autopm_get_interface() fails

Reviewing a fresh portion of coverity defects in USB core
(specifically CID 1458999), Alan Stern noted below in [1]:

On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote:
> A revised search finds line 997 in drivers/usb/core/hub.c and lines
> 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any
> other directories.) AFAICT all three of these should check the
> return value, although a error message in the kernel log probably
> isn't needed.

Factor out the usb_remove_device() change into a standalone patch to
allow conflict-free integration on top of the earliest stable branches.

[1] https://lore.kernel.org/lkml/[email protected]

Fixes: 253e05724f9230 ("USB: add a "remove hardware" sysfs attribute")
Cc: [email protected] # v2.6.33+
Suggested-by: Alan Stern <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
---
v3:
- Newly submitted
---
drivers/usb/core/hub.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1105983b5c1c..54cd8ef795ec 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -988,13 +988,17 @@ int usb_remove_device(struct usb_device *udev)
{
struct usb_hub *hub;
struct usb_interface *intf;
+ int ret;

if (!udev->parent) /* Can't remove a root hub */
return -EINVAL;
hub = usb_hub_to_struct_hub(udev->parent);
intf = to_usb_interface(hub->intfdev);

- usb_autopm_get_interface(intf);
+ ret = usb_autopm_get_interface(intf);
+ if (ret < 0)
+ return ret;
+
set_bit(udev->portnum, hub->removed_bits);
hub_port_logical_disconnect(hub, udev->portnum);
usb_autopm_put_interface(intf);
--
2.25.1

2020-02-26 17:53:42

by Eugeniu Rosca

[permalink] [raw]
Subject: [PATCH v3 3/3] usb: core: port: do error out if usb_autopm_get_interface() fails

Reviewing a fresh portion of coverity defects in USB core
(specifically CID 1458999), Alan Stern noted below in [1]:

On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote:
> A revised search finds line 997 in drivers/usb/core/hub.c and lines
> 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any
> other directories.) AFAICT all three of these should check the
> return value, although a error message in the kernel log probably
> isn't needed.

Factor out the usb_port_runtime_{resume,suspend}() changes into a
standalone patch to allow conflict-free porting on top of stable v3.9+.

[1] https://lore.kernel.org/lkml/[email protected]

Fixes: 971fcd492cebf5 ("usb: add runtime pm support for usb port device")
Cc: [email protected] # v3.9+
Suggested-by: Alan Stern <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
---
v3:
- Newly submitted
---
drivers/usb/core/port.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index bbbb35fa639f..235a7c645503 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -213,7 +213,10 @@ static int usb_port_runtime_resume(struct device *dev)
if (!port_dev->is_superspeed && peer)
pm_runtime_get_sync(&peer->dev);

- usb_autopm_get_interface(intf);
+ retval = usb_autopm_get_interface(intf);
+ if (retval < 0)
+ return retval;
+
retval = usb_hub_set_port_power(hdev, hub, port1, true);
msleep(hub_power_on_good_delay(hub));
if (udev && !retval) {
@@ -266,7 +269,10 @@ static int usb_port_runtime_suspend(struct device *dev)
if (usb_port_block_power_off)
return -EBUSY;

- usb_autopm_get_interface(intf);
+ retval = usb_autopm_get_interface(intf);
+ if (retval < 0)
+ return retval;
+
retval = usb_hub_set_port_power(hdev, hub, port1, false);
usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_CONNECTION);
if (!port_dev->is_superspeed)
--
2.25.1

2020-02-26 18:14:59

by Alan Stern

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] usb: core: hub: fix unhandled return by employing a void function

On Wed, 26 Feb 2020, Eugeniu Rosca wrote:

> Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET):
>
> *** CID 1458999: Error handling issues (CHECKED_RETURN)
> /drivers/usb/core/hub.c: 1869 in hub_probe()
> 1863
> 1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
> 1865 hub->quirk_check_port_auto_suspend = 1;
> 1866
> 1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) {
> 1868 hub->quirk_disable_autosuspend = 1;
> >>> CID 1458999: Error handling issues (CHECKED_RETURN)
> >>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times).
> 1869 usb_autopm_get_interface(intf);
> 1870 }
> 1871
> 1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0)
> 1873 return 0;
> 1874
>
> Rather than checking the return value of 'usb_autopm_get_interface()',
> switch to the usb_autopm_get_interface_no_resume() API, as per:
>
> On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote:
> ------ 8< ------
> > This change (i.e. 'ret = usb_autopm_get_interface') is not necessary,
> > because the resume operation cannot fail at this point (interfaces
> > are always powered-up during probe). A better solution would be to
> > call usb_autopm_get_interface_no_resume() instead.
> ------ 8< ------
>
> Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
> Cc: Hardik Gajjar <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: [email protected] # v4.14+
> Reported-by: [email protected]
> Suggested-by: Alan Stern <[email protected]>
> Signed-off-by: Eugeniu Rosca <[email protected]>

For all three patches:

Acked-by: Alan Stern <[email protected]>

2020-03-03 10:41:19

by Eugeniu Rosca

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] usb: core: hub: fix unhandled return by employing a void function

Hi Greg,

On Wed, Feb 26, 2020 at 01:14:24PM -0500, Alan Stern wrote:
> On Wed, 26 Feb 2020, Eugeniu Rosca wrote:
> >
> > Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
> > Cc: Hardik Gajjar <[email protected]>
> > Cc: Alan Stern <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: [email protected] # v4.14+
> > Reported-by: [email protected]
> > Suggested-by: Alan Stern <[email protected]>
> > Signed-off-by: Eugeniu Rosca <[email protected]>
>
> For all three patches:
>
> Acked-by: Alan Stern <[email protected]>

Friendly reminder to pick up the patches, if no other comments.

--
Best Regards
Eugeniu Rosca

2020-03-03 11:12:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] usb: core: hub: fix unhandled return by employing a void function

On Tue, Mar 03, 2020 at 11:40:05AM +0100, Eugeniu Rosca wrote:
> Hi Greg,
>
> On Wed, Feb 26, 2020 at 01:14:24PM -0500, Alan Stern wrote:
> > On Wed, 26 Feb 2020, Eugeniu Rosca wrote:
> > >
> > > Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub")
> > > Cc: Hardik Gajjar <[email protected]>
> > > Cc: Alan Stern <[email protected]>
> > > Cc: Greg Kroah-Hartman <[email protected]>
> > > Cc: [email protected] # v4.14+
> > > Reported-by: [email protected]
> > > Suggested-by: Alan Stern <[email protected]>
> > > Signed-off-by: Eugeniu Rosca <[email protected]>
> >
> > For all three patches:
> >
> > Acked-by: Alan Stern <[email protected]>
>
> Friendly reminder to pick up the patches, if no other comments.

Less than a week, please give me a chance :)

Don't worry, they are in my to-review queue...

greg k-h