linux-kernel - Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate

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] [day] [month] [year] [list]

Message-ID: <20190314195451.GC6058@hirez.programming.kicks-ass.net>
Date:   Thu, 14 Mar 2019 20:54:51 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Numan Demirdöğen <if.gnu.linux@...il.com>
Cc:     Pavel Machek <pavel@....cz>, jason.low2@....com,
        Waiman.Long@....com, paulmck@...ux.vnet.ibm.com,
        tglx@...utronix.de, dmitry.torokhov@...il.com, mingo@...hat.com,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [regression, bisected] Keyboard not responding after resuming
 from suspend/hibernate

On Tue, Dec 18, 2018 at 10:23:02AM +0300, Numan Demirdöğen wrote:
> I found that passing the options i8042.reset=1 i8042.dumbkbd=1 i8042.direct=1
> results in the keyboard functioning after resume. However, there is a
> long delay before the keyboard or mouse will respond to input on the
> lock screen.[1]

So the thing is, the mutex works, there's nothing wrong or broken about
it (or we'd have known, the kernel would crash and burn). The hand-off
stuff fixed at least one known starvation case as well.

What it does do, is change timing behaviour. But that is something that
is not guaranteed anyway.

This all smells like there's some timing dependent behaviour (aka. race
condition) in the suspend/keyboard interaction _somewhere_.

Now, I know absolutely nothing about either suspend or keyboard stuff,
so I really can't help there. The best idea is to add trace_printk()
throughout the keyboard suspend/resume code and see if there's a clue to
be had there (using remote access to dump the trace buffer after resume,
because of lack of keyboard).

Obviously that takes someone who knows how that should work ...