[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOuDEK1SUMBdxq49G6UxB_DubbM78xUe3w4V062AJ1Ok1NfCHg@mail.gmail.com>
Date: Fri, 16 May 2025 12:45:00 +0800
From: Guan-Yu Lin <guanyulin@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: mathias.nyman@...el.com, stern@...land.harvard.edu, sumit.garg@...nel.org,
gargaditya08@...e.com, kekrby@...il.com, jeff.johnson@....qualcomm.com,
quic_zijuhu@...cinc.com, andriy.shevchenko@...ux.intel.com,
ben@...adent.org.uk, broonie@...nel.org, quic_wcheng@...cinc.com,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v12 2/4] usb: add apis for offload usage tracking
On Fri, Apr 25, 2025 at 7:12 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Wed, Apr 16, 2025 at 02:43:02PM +0000, Guan-Yu Lin wrote:
> > +int usb_offload_put(struct usb_device *udev)
> > +{
> > + int ret;
> > +
> > + if (udev->state == USB_STATE_NOTATTACHED ||
> > + udev->state == USB_STATE_SUSPENDED)
> > + return -EAGAIN;
>
> What's to prevent the state of the device from changing right after you
> check for this?
>
The caller of usb_offload_put() should hold the device lock, so I
think the state of the usb device will remain the same within
usb_offload_put().
> And why -EAGAIN, you don't mention that in the comment for the function.
>
> Also, to pile on, sorry, the coding style needs to be fixed up here :)
>
I'll separate these 2 states into two error handling checks and
provide appropriate error code respectively. Thanks for your advice.
> > +bool usb_offload_check(struct usb_device *udev)
> > +{
> > + struct usb_device *child;
> > + bool active;
> > + int port1;
> > +
> > + usb_hub_for_each_child(udev, port1, child) {
>
> No locking is needed for this loop at all? What happens if a device is
> added or removed while it is looping?
>
Currently the expectation is that all the downstream usb devices
should either go to suspend or be marked as "offload_at_suspend".
Based on this, is there still a chance that usb devices are being
added or removed? My understanding is device addition/removal requires
locks for the upstream usb device, which we've already acquired before
entering usb_offload_check().
> > + device_lock(&child->dev);
> > + active = usb_offload_check(child);
> > + device_unlock(&child->dev);
> > + if (active)
> > + return true;
> > + }
> > +
> > + return !!udev->offload_usage;
>
> But the state can change right afterwards, so no one can do anything
> with this value, right? What is is used for?
>
> thanks,
>
> greg k-h
If we could ensure that all the downstream usb devices satisfy the
following conditions, could the state still change?
1. usb devices either are suspended or marked as "offload_at_suspend".
2. "offload_usage" could only be modified when the usb device is
neither suspended nor marked as "offload_at_suspend".
Regarding point 1, I'll update the function description to state the
function should only be called after we ensure the downstream usb
devices are either suspended or marked as "offload_at_suspend".
Regarding point 2, I'll update the usb_offload_get()/usb_offload_put()
so that "offload_usage" changes only when the device is active and not
marked as "offload_at_suspend".
Regards,
Guan-Yu
Powered by blists - more mailing lists