From: Zhan Xusheng <zhanxusheng1024@gmail.com>
To: gregkh@linuxfoundation.org
Cc: jirislaby@kernel.org, dmitry.torokhov@gmail.com,
mathieu.poirier@linaro.org, linux-serial@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
zhanxusheng@xiaomi.com
Subject: Re: [PATCH v4 1/2] tty: sysrq: don't expose a partially written reset_seq
Date: Fri, 30 Oct 2026 14:30:53 +0800 [thread overview]
Message-ID: <20261030063053.170432-1-zhanxusheng1024@gmail.com> (raw)
In-Reply-To: <2026103031-hungrily-compile-49c8@gregkh>
Hi Greg,
On Fri, Oct 30, 2026 at 07:05:10AM +0100, Greg KH wrote:
> I'm sorry, but I can't really parse this llm-generated text. What is
> the bug here. What is being fixed? And what is changing?
Sorry, that was unreadable.
reset_seq can be changed at runtime, but the new value doesn't work:
each keyboard keeps counting the old keys too, so pressing the new
sequence does nothing. 2/2 fixes that.
1/2 is for a race that 2/2 makes easier to hit. The new list is filled
in one key at a time and the keyboards pick up each partial list, so
pressing the first new key during the write can reboot the machine.
> And how has no one ever hit this issue in the decades that it has been
> present? Is this really something that needs to be fixed? If so, why?
The sequence is usually set on the command line or in DT, and that
works. Both bugs need a runtime change, and the race also needs a key
press during the write, which takes microseconds. I only hit it with
an added delay.
1/2 is far too big for that. Telling the keyboards about the new value
only once the whole list is written avoids the race with a small patch,
and doesn't change what the parameter accepts. I can send that with
2/2 as v5, or drop the series if runtime changes aren't worth fixing.
Thanks,
Zhan Xusheng
next prev parent reply other threads:[~2026-10-30 6:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 4:58 [PATCH v4 0/2] tty: sysrq: fix the reset sequence kept per input device Zhan Xusheng
2026-10-30 4:58 ` [PATCH v4 1/2] tty: sysrq: don't expose a partially written reset_seq Zhan Xusheng
2026-10-30 5:21 ` sashiko-bot
2026-10-30 6:05 ` Greg KH
2026-10-30 6:30 ` Zhan Xusheng [this message]
2026-10-30 7:02 ` Greg KH
2026-10-30 7:58 ` Zhan Xusheng
2026-10-30 8:33 ` Greg KH
2026-10-30 4:58 ` [PATCH v4 2/2] tty: sysrq: reset the per-device key state when reparsing reset_seq Zhan Xusheng
2026-10-30 5:18 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261030063053.170432-1-zhanxusheng1024@gmail.com \
--to=zhanxusheng1024@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=zhanxusheng@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox