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]
Message-ID: <20170613100617.GD29589@mail.corp.redhat.com>
Date:   Tue, 13 Jun 2017 12:06:17 +0200
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Lennart Poettering <mzxreary@...inter.de>
Cc:     Lv Zheng <lv.zheng@...el.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
        Peter Hutterer <peter.hutterer@...-t.net>,
        linux-acpi@...r.kernel.org, systemd-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch
 exported by ACPI

Hi,

[Sorry for the delay, I have been sidetracked from this]

On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> On Thu, 01.06.17 20:46, Benjamin Tissoires (benjamin.tissoires@...hat.com) wrote:
> 
> > Hi,
> > 
> > Sending this as a WIP as it still need a few changes, but it mostly works as
> > expected (still not fully compliant yet).
> > 
> > So this is based on Lennart's comment in [1]: if the LID state is not reliable,
> > the kernel should not export the LID switch device as long as we are not sure
> > about its state.
> 
> Ah nice! I (obviously) like this approach.

Heh. Now I just need to convince Lv that it's the right approach.

> 
> > Note that systemd currently doesn't sync the state when the input node just
> > appears. This is a systemd bug, and it should not be handled by the kernel
> > community.
> 
> Uh if this is borked, we should indeed fix this in systemd. Is there
> already a systemd github bug about this? If not, please create one,
> and we'll look into it!

I don't think there is. I haven't raised it yet because I am not so sure
this will not break again those worthless unreliable LID, and if we play
whack a mole between the kernel and user space, things are going to be
nasty. So I'd rather have this fixed in systemd along with the
unreliable LID switch knowledge, so we are sure that the kernel behaves
the way we expect it to be.

> 
> Thanks for working on this,
> 

No worries.

Cheers,
Benjamin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ