Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.

[Jason Wessel <jason.wessel@windriver.com>]

On 02/26/2012 07:04 PM, Andrei Warkentin wrote:
> Hi,
> 
> ----- Original Message -----
>> From: "Jason Wessel" <jason.wessel@windriver.com>
>> To: "Andrei Warkentin" <andreiw@vmware.com>
>> Cc: kgdb-bugreport@lists.sourceforge.net, linux-kernel@vger.kernel.org
>> Sent: Sunday, February 26, 2012 8:58:37 AM
>> Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.
> 
>>
>> Andrei, if you agree with the attached patch, I'll put it in the
>> merge queue.  If you find problems we can go another iteration. :-)
>>
> 
> Nak. As I've mentioned in my original email, I went down this route as well, only
> to ask the question of why the special ENTER code was there, since all it did
> was introduce problems elsewhere (like repeat ENTER handling, KP ENTER key...).
> This is exactly why my solution was to get rid of the special ENTER code altogether.
> 
> The code in kgdboc already will do input device reset on kdb exit, so there is no need
> to explicitely empty out the keyboard FIFO on every ENTER.
> 

Did you try the patch I sent?  It might not address the key repeat
problem, but this is some thing I had not yet duplicated.  Outside of
the warning message (which was killed off in the patch), was there
garbage characters or some notable behavior?  Was it something you
could see in qemu or only in ESX?

Having authored the keyboard/input handler with some suggestions from
Dmitry, I was fairly certain it had no way to prevent the leak of the
up keystroke unless you have the KDB specific capture where it waits
to act on the "key up" event for an enter keystroke.  The cleanup
handler only cleans up state events where keys were down at the time
the debug core became active.  It will not prevent the leak of key
strokes or state changes while the kernel was stopped.  The goofy
enter handler was supposed to take care of that.

I conclusively proved there is event leakage from using the original
patch you provided. Here is the test case, which you should be able to
execute with qemu or kvm (since you also mentioned that was what you
were previously using).

1) boot the qemu
2) Use kgdboc=kbd
3) break into the debugger to the kdb prompt
4) type "g" but to not press return
5) Connect to the qemu back end debug connection with gdb and set a
   breakpoint at line 402 of atkbd.c which should be the call to:
   	input_event(dev, EV_MSC, MSC_RAW, code);
6) continue the gdb connection
7) In the qemu monitor enter the command:
    sendkey ret 4000

After 4 seconds when the key is released you will catch the leaked
event in the atkbd.c, and if you had X running it propagates all the
way up the input chain.

Jason.