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: <1891343962.20150210234617@eikelenboom.it>
Date:	Tue, 10 Feb 2015 23:46:17 +0100
From:	Sander Eikelenboom <linux@...elenboom.it>
To:	Sander Eikelenboom <linux@...elenboom.it>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-acpi@...r.kernel.org>
Subject: Re: ACPI if power button pressed 1x it creates the same ACPI event twice

Hello Sander,

Monday, January 19, 2015, 2:21:55 PM, you wrote:


> Monday, January 19, 2015, 2:09:34 PM, you wrote:

>> Hello Sander,

>> Tuesday, January 13, 2015, 5:47:24 PM, you wrote:

>>> Tuesday, January 13, 2015, 5:35:10 PM, you wrote:

>>>> Hi Rafael / Len,

>>>> When i press the power-button on my intel NUC, i get twp ACPI power-events shortly 
>>>> after one another (within a second), instead of just one. 

>>>> It doesn't matter if i have the old /proc/acpi interface enabled or disabled in the kernel config.

>>>> I have tested a few older kernels lingering around on the box and 3.14 already 
>>>> has this problem. 3.2 (from the debian repo) doesn't have the problem, it only 
>>>> fires one event.

>>>> I did find another report:
>>>>     Re: lenovo ultrabay docking station: if power button pressed 1x it creates 2x the same ACPI event
>>>>     http://www.spinics.net/lists/linux-acpi/msg54723.html
>>>> But that hasn't come to a conclusion ...


>>>> Unfortunately 3.2 - 3.19-rc4 is a bit of a largish bisect window, so that's 
>>>> unfeasible :-)

>>>> I compiled in apci debug support and tried:
>>>>  echo "0x00080000" > /sys/module/acpi/parameters/debug_layer
>>>>  echo "0xffffffff" > /sys/module/acpi/parameters/debug_level

>>>> But i don't get any extra output in dmesg ?

>>>> Do you have any ideas for a debug patch or better values to figure out what is going on ?

>>>> --
>>>> Sander

>>> Hmm is it normal that it registers in this way (twice) ?

>>> [    5.817980] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
>>> [    5.837907] ACPI: Power Button [PWRB]
>>> [    5.847540] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
>>> [    5.866915] ACPI: Power Button [PWRF]

>>> --
>>> Sander

>> Hi Rafael / Len,

>> Got some more time to test:

>> - It's indeed giving one event for both registered power buttons (which in reality 
>>   are just one hardware button) printing acpid's "%e" revealed that:
>>   1421672289-161192235 | button/power PBTN 00000080 00000000
>>   1421672289-279647745 | button/power LNXPWRBN:00 00000080 00000004

>> So i tested on another box (amd instead of intel), and that also registers 2 
>> power buttons:

>> # dmesg | grep -i button
>> [   13.435060] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
>> [   13.435294] ACPI: Power Button [PWRB]
>> [   13.435495] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
>> [   13.435683] ACPI: Power Button [PWRF]
>>  
>> So the question is .. should both register and should scripts adjust to pick up just one of them ?
>> Or can, as a more general solution, just one be ignored when registering ?

>> --
>> Sander

> Whoops sorry for the fragmentation of the report ... but just thought the output 
> under kernel 3.2.0 could be handy as well .. as that only fires one event:

> [    4.003753] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
> [    4.003838] ACPI: Power Button [PWRB]
> [    4.003977] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
> [    4.005530] ACPI: Power Button [PWRF]

> It registers also two ..
> But when the power button is pressed only fires this one:

> 1421673524-817561070 | button/power PBTN 00000080 00000000

> --
> Sander

Hi Rafael / Len,

Unfortunately haven't heard anything back .. and with 3.19-rc6 it seems 
miraculously fixed, i receive only one event on a powerbutton press.

However with 3.19.0 (final) .. it was back again .. 1 press .. 2 events.

So i bisected ... but i came out on the netlink commit below. Now seems acpid to 
be using input layer and netlink if the deprecated /proc/apci/events is not compiled in (which 
isn't at present) according to [1]. 

But how the fsck this relates to one another... the only thing i can imagine is 
that i have to take that text literal: It uses both input layer and netlink 
simultaneously and will receive an event via both of those ways which slightly 
differ in naming but have the same origin ?

acpid used is debian wheezy: acpid 1:2.0.16-1+deb7u1 amd64 Advanced Configuration and Power Interface event daemon

--
Sander

[1] http://manpages.ubuntu.com/manpages/precise/man8/acpid.8.html



8b7c36d810c61ab16997f4387fc16291410700f8 is the first bad commit
commit 8b7c36d810c61ab16997f4387fc16291410700f8
Author: Pablo Neira <pablo@...filter.org>
Date:   Thu Jan 29 10:51:53 2015 +0100

    netlink: fix wrong subscription bitmask to group mapping in

    The subscription bitmask passed via struct sockaddr_nl is converted to
    the group number when calling the netlink_bind() and netlink_unbind()
    callbacks.

    The conversion is however incorrect since bitmask (1 << 0) needs to be
    mapped to group number 1. Note that you cannot specify the group number 0
    (usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
    since this is rejected through -EINVAL.

    This problem became noticeable since 97840cb ("netfilter: nfnetlink:
    fix insufficient validation in nfnetlink_bind") when binding to bitmask
    (1 << 0) in ctnetlink.

    Reported-by: Andre Tomt <andre@...t.net>
    Reported-by: Ivan Delalande <colona@...sta.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
    Signed-off-by: David S. Miller <davem@...emloft.net>

:040000 040000 1a624f23ebb1006bcd734f850c2350bdce751356 e24acc011aea2048599514ed278582a27265fab6 M      net
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ