Driver core holds a reference to the USB device while it is bound to a
driver and there is no need to take additional references unless the
structure is needed after disconnect.

Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/usb/usbip/stub_dev.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 34990b7e2d18..abfa11d6bde7 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -267,7 +267,7 @@ static struct stub_device *stub_device_alloc(struct usb_device *udev)
 	if (!sdev)
 		return NULL;
 
-	sdev->udev = usb_get_dev(udev);
+	sdev->udev = udev;
 
 	/*
 	 * devid is defined with devnum when this driver is first allocated.
@@ -409,7 +409,6 @@ static int stub_probe(struct usb_device *udev)
 	put_busid_priv(busid_priv);
 
 sdev_free:
-	usb_put_dev(udev);
 	stub_device_free(sdev);
 
 	return rc;
@@ -488,8 +487,6 @@ static void stub_disconnect(struct usb_device *udev)
 	/* shutdown the current connection */
 	shutdown_busid(busid_priv);
 
-	usb_put_dev(sdev->udev);
-
 	/* we already have busid_priv, just lock busid_lock */
 	spin_lock(&busid_priv->busid_lock);
 	/* free sdev */
-- 
2.52.0

On 3/5/26 06:38, Johan Hovold wrote:
> Driver core holds a reference to the USB device while it is bound to a
> driver and there is no need to take additional references unless the
> structure is needed after disconnect.
> 

In this case it is necessary for stub driver to hang on to the reference
to maintain exported device status.

thanks,
-- Shuah

On Mon, Mar 09, 2026 at 02:26:03PM -0600, Shuah Khan wrote:
> On 3/5/26 06:38, Johan Hovold wrote:
> > Driver core holds a reference to the USB device while it is bound to a
> > driver and there is no need to take additional references unless the
> > structure is needed after disconnect.
> 
> In this case it is necessary for stub driver to hang on to the reference
> to maintain exported device status.

But the driver does not hold on to the reference taken at probe after
disconnect returns. The stub device itself is even freed at disconnect
and cannot be used to release the reference.

Which exported device status are you referring to here?

Johan

On 3/10/26 02:35, Johan Hovold wrote:
> On Mon, Mar 09, 2026 at 02:26:03PM -0600, Shuah Khan wrote:
>> On 3/5/26 06:38, Johan Hovold wrote:
>>> Driver core holds a reference to the USB device while it is bound to a
>>> driver and there is no need to take additional references unless the
>>> structure is needed after disconnect.
>>
>> In this case it is necessary for stub driver to hang on to the reference
>> to maintain exported device status.
> 
> But the driver does not hold on to the reference taken at probe after
> disconnect returns. The stub device itself is even freed at disconnect
> and cannot be used to release the reference.
> 
> Which exported device status are you referring to here?

I am referring to the device status that usbip host exports to
the client side. The interaction between host and client is
handled from stub rx, tx, and also event handler.

Having the reference to the device helps so the device sticks
around until the stub driver no longer needs it so we don't see
use after free type issues.

thanks,
-- Shuah

On Tue, Mar 10, 2026 at 03:51:41PM -0600, Shuah Khan wrote:
> On 3/10/26 02:35, Johan Hovold wrote:
> > On Mon, Mar 09, 2026 at 02:26:03PM -0600, Shuah Khan wrote:
> >> On 3/5/26 06:38, Johan Hovold wrote:
> >>> Driver core holds a reference to the USB device while it is bound to a
> >>> driver and there is no need to take additional references unless the
> >>> structure is needed after disconnect.
> >>
> >> In this case it is necessary for stub driver to hang on to the reference
> >> to maintain exported device status.
> > 
> > But the driver does not hold on to the reference taken at probe after
> > disconnect returns. The stub device itself is even freed at disconnect
> > and cannot be used to release the reference.
> > 
> > Which exported device status are you referring to here?
> 
> I am referring to the device status that usbip host exports to
> the client side. The interaction between host and client is
> handled from stub rx, tx, and also event handler.
> 
> Having the reference to the device helps so the device sticks
> around until the stub driver no longer needs it so we don't see
> use after free type issues.

But the driver drops the reference that it takes during probe at
disconnect, which makes that reference completely redundant as driver
core guarantees that the device won't go away while a driver is bound.

So that particular reference doesn't help with anything.

Johan

On 3/11/26 02:02, Johan Hovold wrote:
> On Tue, Mar 10, 2026 at 03:51:41PM -0600, Shuah Khan wrote:
>> On 3/10/26 02:35, Johan Hovold wrote:
>>> On Mon, Mar 09, 2026 at 02:26:03PM -0600, Shuah Khan wrote:
>>>> On 3/5/26 06:38, Johan Hovold wrote:
>>>>> Driver core holds a reference to the USB device while it is bound to a
>>>>> driver and there is no need to take additional references unless the
>>>>> structure is needed after disconnect.
>>>>
>>>> In this case it is necessary for stub driver to hang on to the reference
>>>> to maintain exported device status.
>>>
>>> But the driver does not hold on to the reference taken at probe after
>>> disconnect returns. The stub device itself is even freed at disconnect
>>> and cannot be used to release the reference.
>>>
>>> Which exported device status are you referring to here?
>>
>> I am referring to the device status that usbip host exports to
>> the client side. The interaction between host and client is
>> handled from stub rx, tx, and also event handler.
>>
>> Having the reference to the device helps so the device sticks
>> around until the stub driver no longer needs it so we don't see
>> use after free type issues.
> 
> But the driver drops the reference that it takes during probe at
> disconnect, which makes that reference completely redundant as driver
> core guarantees that the device won't go away while a driver is bound.
> 
> So that particular reference doesn't help with anything.

I am concerned about stub_rx and stub_tx running to handle any
packets that come in after while stub driver is in the middle of
disconnect.

Currently it has the reference while it handles reset events coming
from event handler in usbip_in_eh() and until shutdown_busid(busid_priv)
is complete.

We can make this change and run it through some tests.

thanks,
-- Shuah