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]
Date: Mon, 12 Feb 2024 14:04:31 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
  Ricardo Ribalda <ribalda@...omium.org>,
  Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
  Mauro Carvalho Chehab <mchehab@...nel.org>, linux-usb@...r.kernel.org,
  linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
  stable@...r.kernel.org
Subject: Re: [PATCH v4] media: ucvideo: Add quirk for Logitech Rally Bar

On Mon, Feb 12, 2024 at 01:22:42PM +0100, Oliver Neukum wrote:
> On 04.02.24 11:52, Laurent Pinchart wrote:
> > Hi Ricardo,
> > 
> > Thank you for the patch.
> 
> Hi,
> 
> sorry for commenting on this late, but this patch has
> a fundamental issue. In fact this issue is the reason the
> handling for quirks is in usbcore at all.
> 
> If you leave the setting/clearing of this flag to a driver you
> are introducing a race condition. The driver may or may not be
> present at the time a device is enumerated. And you have
> no idea how long the autosuspend delay is on a system
> and what its default policy is regarding suspending
> devices.
> That means that a device can have been suspended and
> resumed before it is probed. On a device that needs
> RESET_RESUME, we are in trouble.

Not necessarily.  If the driver knows that one of these devices may 
already have been suspend and resumed, it can issue its own preemptive 
reset at probe time.

> The inverse issue will arise if a device does not react
> well to RESET_RESUME. You cannot rule out that a device
> that must not be reset will be reset.

That's a separate issue, with its own list of potential problems.

> I am sorry, but it seems to me that the exceptions need
> to go into usbcore.

If we do then we may want to come up with a better scheme for seeing 
which devices need to have a quirk flag set.  A static listing probably 
won't be good enough; the decision may have to be made dynamically.

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ