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:   Thu, 9 Jun 2022 17:59:36 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: Re: [PATCH v1 00/16] ACPI: Get rid of the list of children in struct acpi_device

On Thu, Jun 9, 2022 at 5:57 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Thu, Jun 09, 2022 at 03:44:27PM +0200, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > Confusingly enough, the ACPI subsystem stores the information on the given ACPI
> > device's children in two places: as the list of children in struct acpi_device
> > and (as a result of device registration) in the list of children in the embedded
> > struct device.
> >
> > These two lists agree with each other most of the time, but not always (like in
> > error paths in some cases), and the list of children in struct acpi_device is
> > not generally safe to use without locking.  In principle, it should always be
> > walked under acpi_device_lock, but in practice holding acpi_scan_lock is
> > sufficient for that too.  However, its users may not know whether or not
> > they operate under acpi_scan_lock and at least in some cases it is not accessed
> > in a safe way (note that ACPI devices may go away as a result of hot-remove,
> > unlike OF nodes).
> >
> > For this reason, it is better to consolidate the code that needs to walk the
> > children of an ACPI device which is the purpose of this patch series.
> >
> > Overall, it switches over all of the users of the list of children in struct
> > acpi_device to using helpers based on the driver core's mechanics and finally
> > drops that list, but some extra cleanups are done on the way.
> >
> > Please refer to the patch changelogs for details.
>
> Cool series, thanks for doing that!
>
> You may add my
> Revieweed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> to all non-commented, by me, patches (excluding soundwire) and to ones
> where comment just about one line/two lines split (address them if you
> are okay, otherwise ignore those comments).

Thank you!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ