From: Zhan Xusheng <zhanxusheng1024@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
Sashiko <sashiko-bot@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH v3 1/2] tty: sysrq: reparse the reset sequence when its length changes
Date: Wed, 21 Oct 2026 10:20:06 +0800 [thread overview]
Message-ID: <20261021022007.1717207-2-zhanxusheng1024@gmail.com> (raw)
In-Reply-To: <20261021022007.1717207-1-zhanxusheng1024@gmail.com>
From: Zhan Xusheng <zhanxusheng@xiaomi.com>
reset_seq is a module parameter array, so a write to it is handled by
param_array(), which publishes the new length only after the element
setter has already bumped the version:
kernel/params.c:
*num = 0; /* sysrq_reset_seq_len */
do {
ret = set(val, &kp); /* bumps the version */
...
(*num)++;
} while (save == ',');
sysrq_handle_keypress() decides to reparse purely on the version, so a
keypress landing between the last setter and the matching (*num)++ parses
a sequence that is one element short and then latches the final version.
Nothing makes it reparse afterwards, so the device keeps the truncated
sequence until the parameter is written again.
On a device that has not parsed before, a two-key sequence truncated this
way leaves reset_seq_len at 1. The parse runs before the keypress is
recorded in key_down, so reset_seq_cnt is 0 and reset_canceled stays
false. A single press of the remaining key then satisfies
if (++state->reset_seq_cnt == state->reset_seq_len &&
!state->reset_canceled)
and sysrq_handle_reset_request() goes straight to orderly_reboot(),
because sysrq_downtime_ms defaults to 0.
Record the length the parse used and treat a change in it as staleness
too. The truncated parse then no longer sticks: once param_array() has
published the final length, the next keypress reparses.
Fixes: 154b7a489a5b ("Input: sysrq - allow specifying alternate reset sequence")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/sashiko-outbox-173915@kernel.org/
Cc: stable@vger.kernel.org
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
drivers/tty/sysrq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index c2e4b31b699aa..4fd5b3ace9c40 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -676,6 +676,7 @@ struct sysrq_state {
int reset_seq_len;
int reset_seq_cnt;
int reset_seq_version;
+ unsigned int reset_seq_parsed_len;
struct timer_list keyreset_timer;
};
@@ -686,12 +687,13 @@ static unsigned int sysrq_reset_seq_version = 1;
static void sysrq_parse_reset_sequence(struct sysrq_state *state)
{
+ unsigned int len = READ_ONCE(sysrq_reset_seq_len);
int i;
unsigned short key;
state->reset_seq_cnt = 0;
- for (i = 0; i < sysrq_reset_seq_len; i++) {
+ for (i = 0; i < len; i++) {
key = sysrq_reset_seq[i];
if (key == KEY_RESERVED || key > KEY_MAX)
@@ -708,6 +710,7 @@ static void sysrq_parse_reset_sequence(struct sysrq_state *state)
state->reset_canceled = state->reset_seq_cnt != 0;
state->reset_seq_version = sysrq_reset_seq_version;
+ state->reset_seq_parsed_len = len;
}
static void sysrq_do_reset(struct timer_list *t)
@@ -903,7 +906,9 @@ static bool sysrq_handle_keypress(struct sysrq_state *sysrq,
/*
* See if reset sequence has changed since the last time.
*/
- if (sysrq->reset_seq_version != sysrq_reset_seq_version)
+ if (sysrq->reset_seq_version != sysrq_reset_seq_version ||
+ sysrq->reset_seq_parsed_len !=
+ READ_ONCE(sysrq_reset_seq_len))
sysrq_parse_reset_sequence(sysrq);
/*
--
2.43.0
next prev parent reply other threads:[~2026-10-21 2:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 2:20 [PATCH v3 0/2] tty: sysrq: fix the reset sequence state kept per input device Zhan Xusheng
2026-10-21 2:20 ` Zhan Xusheng [this message]
2026-10-21 2:20 ` [PATCH v3 2/2] tty: sysrq: reset the per-device key state when reparsing reset_seq Zhan Xusheng
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=20261021022007.1717207-2-zhanxusheng1024@gmail.com \
--to=zhanxusheng1024@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.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
all inboxes | Powered by JetHome®