From: Greg KH <gregkh@linuxfoundation.org>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>
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 09:33:41 +0100 [thread overview]
Message-ID: <2026103043-tributary-partake-aefd@gregkh> (raw)
In-Reply-To: <20261030075820.207049-1-zhanxusheng1024@gmail.com>
On Fri, Oct 30, 2026 at 03:58:20PM +0800, Zhan Xusheng wrote:
> Hi Greg,
>
> On Fri, Oct 30, 2026 at 08:02:30AM +0100, Greg KH wrote:
> > I still don't understand what the root problem is here, sorry.
>
> Each keyboard keeps its own copy of reset_seq. It rebuilds the copy on
> the first key press after the parameter changes, and it rebuilds it
> wrong in two ways.
>
> 1) It adds the new keys to the old copy instead of replacing it (2/2):
>
> echo 56,29,111 > /sys/module/sysrq/parameters/reset_seq # Alt+Ctrl+Del
> (press any key)
> echo 59,60 > /sys/module/sysrq/parameters/reset_seq # F1+F2
>
> Now F1+F2 does nothing. Only holding all five keys resets. So setting
> reset_seq once works, but changing it later does not.
So this feature has never worked? Or it is just "one change only"? So
your change is an addition to the feature, not a bugfix?
> 2) It can rebuild the copy while the write is half done (1/2). The
> write stores the keys one at a time, and the keyboard may read the list
> in between:
>
> echo 59,60 > reset_seq
> store 59
> <- F1 pressed: keyboard reads "59" as the sequence
> store 60
>
> On a keyboard that has not used a reset sequence before, or on any
> keyboard once 2/2 is applied, that F1 press completes the one-key
> sequence and reboots the machine. The window is microseconds; I only
> hit it with an added delay.
So this isn't a "real" issue? If you are modifying the key sequence,
how can you press the key at the same time? Doing "major" rework for
that might just not be worth it.
thanks,
greg k-h
next prev parent reply other threads:[~2026-10-30 8:33 UTC|newest]
Thread overview: 12+ 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
2026-10-30 7:02 ` Greg KH
2026-10-30 7:58 ` Zhan Xusheng
2026-10-30 8:33 ` Greg KH [this message]
2026-10-30 11:33 ` Zhan Xusheng
2026-10-30 11:48 ` 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=2026103043-tributary-partake-aefd@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dmitry.torokhov@gmail.com \
--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=zhanxusheng1024@gmail.com \
--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