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] [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

Powered by Openwall GNU/*/Linux Powered by OpenVZ