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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOuDEK04r+1j-R7EmMEu91OGwmjY8AaViyQgVK4uShouTLZFiw@mail.gmail.com>
Date: Thu, 29 Feb 2024 18:09:00 +0800
From: Guan-Yu Lin <guanyulin@...gle.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: pavel@....cz, len.brown@...el.com, gregkh@...uxfoundation.org, 
	andriy.shevchenko@...ux.intel.com, rdunlap@...radead.org, james@...iv.tech, 
	broonie@...nel.org, james.clark@....com, masahiroy@...nel.org, 
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v3] PM / core: conditionally skip system pm in
 device/driver model

On Tue, Feb 27, 2024 at 7:28 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Mon, Feb 26, 2024 at 10:45 AM Guan-Yu Lin <guanyulin@...gle.com> wrote:
> >
> > On Sat, Feb 24, 2024 at 1:44 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > >
> > > On Fri, Feb 23, 2024 at 3:38 PM Guan-Yu Lin <guanyulin@...glecom> wrote:
> > > >
> > > > In systems with a main processor and a co-processor, asynchronous
> > > > controller management can lead to conflicts.  One example is the main
> > > > processor attempting to suspend a device while the co-processor is
> > > > actively using it. To address this, we introduce a new sysfs entry
> > > > called "conditional_skip". This entry allows the system to selectively
> > > > skip certain device power management state transitions. To use this
> > > > feature, set the value in "conditional_skip" to indicate the type of
> > > > state transition you want to avoid.  Please review /Documentation/ABI/
> > > > testing/sysfs-devices-power for more detailed information.
> > > >
> > > > Signed-off-by: Guan-Yu Lin <guanyulin@...gle.com>
> > >
> > > Please explain how this is intended to work.  That is, what exactly
> > > you expect to happen when the new attribute is set.
> >
> > The sysfs entry 'conditional_skip' for a device indicates which power
> > transitions (e.g. PM_EVENT_SUSPEND) are omitted within the system
> > power management flow. During the processing of an identified power
> > transition, the device's power.entry will not be added to the
> > dpm_prepared_list, preventing the device from undergoing that
> > transition. As 'conditional_skip' is modifiable at runtime, a device's
> > participation in system power management can be dynamically enabled or
> > disabled.
>
> So this idea is completely misguided AFAICS.
>
> First off, why would a device be skipped in system-wide suspend and
> not in hibernation?  Or the other way around?  Or why would it be
> skipped in one phase of hibernation and not in the other?
>

The motto is to set less constraints and let users configure them
properly by themselves. But, we could redesign it to better match with
existing conventions/regulations.

> Second, but not less important, why is skipping a device in
> system-wide transitions a good idea at all?  What about dependencies
> between that device and the other devices in the system?
>

If a device is also used by another operating system kernel, then
Linux kernel shouldn't always do the system power transition on that
device to avoid affecting another operating system kernel.

Since device dependencies can be highly system-specific, maybe we
should let users handle it as users are the only ones who understand
their system's unique configuration.

> Generally speaking, system-wide PM is designed to cover the entire
> system and there are good reasons for that.  If you don't want it to
> cover the entire system, you cannot use it at all.

We discovered a use case that the existing system-wide PM may not
fully support: devices shared by multiple operating system kernels. I
think supporting this case would be beneficial to the system-wide PM,
as it would increase its compatibility.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ