Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

2019-11-05 Thread Matthew Garrett
On Tue, Nov 5, 2019 at 8:33 AM Chris Murphy  wrote:
>
> On Fri, Nov 1, 2019 at 2:31 PM Matthew Garrett  wrote:
> >
> > The initrd already contains a UI stack in order to permit disk unlock
> > at boot time, so this really doesn't seem like a problem?
>
> It's a very small and limited UI stack. At least the GNOME developers
> I've discussed it with, this environment has all kinds of a11y, i18n,
> and keymapping problems. To solve it means either baking a significant
> portion of the GNOME stack into the initramfs, or some kind of magic
> because the resources don't exist to create a minimized GNOME stack
> that could achieve this. And so far the effort has been to try and
> make the initramfs smaller, and more generic.

I agree that the Plymouth UI stack isn't ideal for various reasons,
but it's the UI stack that's used for unlocking the drive during boot
so reusing it doesn't make things any worse than they already are.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

2019-11-01 Thread Matthew Garrett
On Thu, Oct 31, 2019 at 5:06 PM Lennart Poettering
 wrote:
> Paging doesn't allow that really. It's always ugly. You'd have to have
> your own UI stack in the initrd, i.e. basically have an alternative
> root disk, that possesses the screen exclusively as long as the system
> is up but not unlocked yet.

The initrd already contains a UI stack in order to permit disk unlock
at boot time, so this really doesn't seem like a problem? Switch VTs
before suspend, suspend the LUKS devices so all access blocks and the
keys are dropped, suspend, resume, run the unlock codepath from
initramfs again, switch VTs back, we're good? Things are a little more
complicated if you want to use the disk unlock phrase to also trigger
desktop unlock, but everything else seems reasonably straightforward -
processes will sit in D state until unlocked, but time will continue
as expected.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd and chroot()

2019-06-04 Thread Matthew Garrett
On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson  wrote:
> AVC avc:  denied  { sys_chroot } for  pid=2919 comm="rpc.mountd" 
> capability=18  scontext=system_u:system_r:nfsd_t:s0 
> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=0

This is an SELinux policy violation, nothing to do with systemd.
You're probably not seeing it when you run the daemon by hand because
the SELinux policy doesn't specify a transition in that case, so the
daemon doesn't end up running in the confined context.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

2019-05-14 Thread Matthew Garrett
> The point I was trying to make was: "CPUID" and the model-specific registers
> (thus the name) depend very much on the CPU being used. While the kernel makes
> grat efforts to get things right, I wondered whether it's the best idea 
> whether
> to repeat that effort in an application program.

Compiler intrinsics are supposed to provide correct results
independent of the OS that they're running on. It's not unreasonable
for code to expect them to behave correctly. In this case it seems
that an assumption that gcc made that's true for most CPUs isn't true
for a specific (20 years old) CPU - that's a bug in gcc, and it's
reasonable to ask for it to be fixed. There's a separate question of
whether depending on the kernel for this information rather than using
the compiler was the best solution, but it's pretty justified for
applications to presume that the compiler works the way that the
compiler is documented as behaving.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers

2015-04-19 Thread Matthew Garrett
On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote:
 On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
  1) having this in udev makes it easier for users to alter the
  configuration - the kernel can then afford to be conservative until we
  enable power management, rather than potentially breaking the device the
  moment pm is enabled without any ability to recover it.
 
 There is no significant difference between a default unconditional
 udev setting and a kernel command line option to control such behavior
 if needed.

The command line option would need to be per-device, so I can't see a 
terribly good way to express that.

  2) this config is currently static, but the appropriate policy may turn
  out to be more complicated in some scenarios (interactions between
  devices and their upstream bridges, for instance, or USB Bluetooth
  controllers that are on-die with a PCI wifi controller without having a
  common exposed bus topology yet still having pm interactions). Splitting
  this between udev and the kernel makes it more difficult to determine
  the source of the policy and debug it.
 
 Either the setting is safe to use or not, the source of this policy is
 not really relevant here. The loop through userspace does not sound
 useful.

There's no mechanism in the kernel to say Enable power management on 
this USB device only if a specific PCI device doesn't exist. This kind 
of policy is much easier to express in userspace than in the kernel.

  3) we already have examples of this in udev, so people already expect to
  find it here.
 
 Which should be a reason to carefully check these examples if they
 should stay in udev, not a reason to justify to add more.

Well, that's certainly an option.

 I'm not convinced that any such broad matches for power management
 belong into udev at all. Udev can carry specific device matches, or
 carry data that cannot be determined from the device itself, like the
 mouse resolution and such, but like in these rules, reading the vendor
 from the kernel and unconditionally flipping a bit back into the
 kernel does not look like a task for udev or userspace in general.

Is there any possibility that you can be convinced?
-- 
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers

2015-04-18 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com

If a Bluetooth controller is built into the machine, it should be safe to
enable runtime power management on it. Let's do so.
---
 Makefile.am | 3 ++-
 rules/90-usb-bluetooth-pm.rules | 8 
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 rules/90-usb-bluetooth-pm.rules

diff --git a/Makefile.am b/Makefile.am
index 40cf101..8463a54 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3754,7 +3754,8 @@ dist_udevrules_DATA += \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
rules/90-hda-controller-pm.rules \
-   rules/90-hda-codec-pm.rules
+   rules/90-hda-codec-pm.rules \
+   rules/90-usb-bluetooth-pm.rules
 
 nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-usb-bluetooth-pm.rules b/rules/90-usb-bluetooth-pm.rules
new file mode 100644
index 000..ea535f0
--- /dev/null
+++ b/rules/90-usb-bluetooth-pm.rules
@@ -0,0 +1,8 @@
+# USB devices that are internal to the machine should also be safe to 
autosuspend
+
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTR{removable}==removable, GOTO=usb_bluetooth_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTR{removable}==unknown, GOTO=usb_bluetooth_pm_end
+
+ACTION==add, SUBSYSTEM==usb, ATTR{bDeviceClass}==e0, 
ATTR{bDeviceSubClass}==01, ATTR{bDeviceProtocol}==01, 
TEST==power/control, ATTR{power/control}=auto
+
+LABEL=usb_bluetooth_pm_end
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/3] rules: Enable runtime device power management on a subset of HDA codecs

2015-04-18 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com

4.1 ports HDA codec power management to the standard runtime PM framework,
which means we have per-codec control over whether it's enabled or not.
We've traditionally left this disabled because on some codecs enabling it
causes popping noises on power transitions, but now we can whitelist on a
per-codec basis. This patch simply enables it for the Broadwell HDMI codec
with the aim that we can add more based on user feedback.
---
 Makefile.am | 3 ++-
 rules/90-hda-codec-pm.rules | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 rules/90-hda-codec-pm.rules

diff --git a/Makefile.am b/Makefile.am
index d23c428..40cf101 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3753,7 +3753,8 @@ dist_udevrules_DATA += \
rules/75-net-description.rules \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
-   rules/90-hda-controller-pm.rules
+   rules/90-hda-controller-pm.rules \
+   rules/90-hda-codec-pm.rules
 
 nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-codec-pm.rules b/rules/90-hda-codec-pm.rules
new file mode 100644
index 000..e0c55e1
--- /dev/null
+++ b/rules/90-hda-codec-pm.rules
@@ -0,0 +1,4 @@
+# Enable autosuspend for some HDA codecs 
+
+ACTION==add, SUBSYSTEM==hdaudio, ATTR{chip_name}==Broadwell HDMI, 
ATTR{power/control}=auto
+
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Enable runtime power management on more hardware

2015-04-18 Thread Matthew Garrett
Modern hardware is very sensitive to peripheral power management state. While
the kernel supports runtime PM on a lot of hardware, it's mostly disabled by
default due to the risk of it breaking a subset of devices. Let's turn it on
on devices where we have reasonable confidence in it working, with the aim of
extending this to more devices as we receive user feedback.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers

2015-04-18 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com

PCI power management seems to work fine on Intel HDA controllers, so let's
turn that on. We can expand this to other vendors based on user feedback.
---
 Makefile.am  | 3 ++-
 rules/90-hda-controller-pm.rules | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 rules/90-hda-controller-pm.rules

diff --git a/Makefile.am b/Makefile.am
index 68d8252..d23c428 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3752,7 +3752,8 @@ dist_udevrules_DATA += \
rules/70-touchpad.rules \
rules/75-net-description.rules \
rules/78-sound-card.rules \
-   rules/80-net-setup-link.rules
+   rules/80-net-setup-link.rules \
+   rules/90-hda-controller-pm.rules
 
 nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-controller-pm.rules b/rules/90-hda-controller-pm.rules
new file mode 100644
index 000..2f915be
--- /dev/null
+++ b/rules/90-hda-controller-pm.rules
@@ -0,0 +1,3 @@
+# Enable autosuspend for some HDA interfaces
+
+ACTION==add, SUBSYSTEM==pci, ATTR{class}==0x040300, 
ATTR{vendor}==0x8086, ATTR{power/control}=auto
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers

2015-04-18 Thread Matthew Garrett
(Resending from the correct address)

On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote:

 It looks like an unconditional static assignment.
 
 
 Why should udev carry this? We generally do not want to do things like
 that. Udev can help if there is conditional policy or complex
 cross-subsystem knowledge is needed, but this looks just like a job
 for the kernel and not userspace.

1) having this in udev makes it easier for users to alter the 
configuration - the kernel can then afford to be conservative until we 
enable power management, rather than potentially breaking the device the 
moment pm is enabled without any ability to recover it.

2) this config is currently static, but the appropriate policy may turn 
out to be more complicated in some scenarios (interactions between 
devices and their upstream bridges, for instance, or USB Bluetooth 
controllers that are on-die with a PCI wifi controller without having a 
common exposed bus topology yet still having pm interactions). Splitting 
this between udev and the kernel makes it more difficult to determine 
the source of the policy and debug it.

3) we already have examples of this in udev, so people already expect to 
find it here. 

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] 42-usb-hid-pm.rules: Fix tests for removable state

2015-04-08 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com

We only care about whether our direct parent is removable, not whether any
further points up the tree are - the kernel will take care of policy for
those itself. This enables autosuspend on devices where the root hub reports
that its removable state is unknown.
---
 rules/42-usb-hid-pm.rules | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index 4c300da..3721219 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -28,9 +28,9 @@ ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==14dd, 
ATTR{idProduct}==0002
 
 # USB HID devices that are internal to the machine should also be safe to 
autosuspend
 
-ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTRS{removable}==removable, GOTO=usb_hid_pm_end
-ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTRS{removable}==unknown, GOTO=usb_hid_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTR{../removable}==removable, GOTO=usb_hid_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb, 
ATTR{../removable}==unknown, GOTO=usb_hid_pm_end
 
-ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03, 
ATTRS{removable}==fixed, TEST==../power/control, 
ATTR{../power/control}=auto
+ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03, 
ATTR{../removable}==fixed, TEST==../power/control, 
ATTR{../power/control}=auto
 
 LABEL=usb_hid_pm_end
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Add support for Intel Rapid Start

2013-10-13 Thread Matthew Garrett
On Sun, Oct 13, 2013 at 10:09:28PM +0200, Bastien Nocera wrote:
 On Sun, 2013-10-13 at 20:57 +0100, Matthew Garrett wrote:
  On Sun, Oct 13, 2013 at 09:50:59PM +0200, Bastien Nocera wrote:
  
   +r = 
   read_one_line_file(/sys/bus/acpi/devices/INT3392:00/wakeup_events, p);
  
  /sys/bus/acpi/drivers/intel_rapid_start/*/wakeup_events would be better, 
  if there's any way to use wildcards here. It's possible that later 
  models will change the ACPI ID while still exposing the same userspace 
  UI.
 
 There's no way to use globs here, but I can look for the first directory
 under there, would that be enough? systemd developers, is there a helper
 for that already?

Hrm. What defines first directory? There's also a module directory, 
which makes things harder. I guess there's an argument for integrating 
this into the core kernel power management in some way - I'll talk to 
Rafael about that in Edinburgh.

 Then we shouldn't check the value, and set it, but I'm not sure I should
 be doing that in the has_rapid_start() function.

Sounds fair.

 I guess that in the future, we should allow setting and modifying the
 wakeup timer value, but I'd want to figure out if and how to present it
 in the UI before that. I'd be happy with a decent default value like 2
 hours and be done with it.

Sure.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Add support for Intel Rapid Start

2013-10-13 Thread Matthew Garrett
On Sun, Oct 13, 2013 at 09:50:59PM +0200, Bastien Nocera wrote:

 +r = 
 read_one_line_file(/sys/bus/acpi/devices/INT3392:00/wakeup_events, p);

/sys/bus/acpi/drivers/intel_rapid_start/*/wakeup_events would be better, 
if there's any way to use wildcards here. It's possible that later 
models will change the ACPI ID while still exposing the same userspace 
UI.

 +/* We only support rapid start if we have both values set:
 + * 1: Wake to enter hibernation when the wakeup timer expires
 + * 2: Wake to enter hibernation when the battery reaches a
 + * critical level */
 +if (p[0] == '3'  p[1] == '\0')
 +return true;

That seems a little harsh - not all firmware exposes the settings for 
this. I think it's legitimate to just program it yourself.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supermicro X8ST3 KVM-over-IP keyboard doesn't work with the existing rule in 42-usb-hid-pm.rules

2012-12-06 Thread Matthew Garrett
On Thu, Dec 06, 2012 at 05:05:17PM +0100, Kay Sievers wrote:
 Matthew, any idea?
 Remove the rule?

Sure. My suspicion is that this is fine with some firmware versions, but 
figuring out which is going to be a pain. Probably easiest to drop it.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel