From: sashiko-bot@kernel.org
To: "Zhan Xusheng" <zhanxusheng1024@gmail.com>
Cc: linux-input@vger.kernel.org, linux-serial@vger.kernel.org,
dmitry.torokhov@gmail.com
Subject: Re: [PATCH] Input: sysrq - reset the per-device key state when reparsing reset_seq
Date: Fri, 16 Oct 2026 03:41:33 +0000 [thread overview]
Message-ID: <sashiko-outbox-173692@kernel.org> (raw)
In-Reply-To: <20261016032732.2328852-1-zhanxusheng@xiaomi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tty: sysrq: uncancelable reset timer on sequence change
--
commit 2166ad442fbe41cfd64e5275427188db06092a2e
Author: Zhan Xusheng <zhanxusheng1024@gmail.com>
Input: sysrq - reset the per-device key state when reparsing reset_seq
This commit clears the accumulated reset_seq_len and reset_keybit state when
reparsing the reset sequence. This prevents stale keys from affecting the reset
detection, as the previous code only cleared reset_seq_cnt.
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index c2e4b31b699aa..d28a4726b07fc 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -689,6 +689,8 @@ static void sysrq_parse_reset_sequence(struct sysrq_state *state)
> int i;
> unsigned short key;
>
> + bitmap_zero(state->reset_keybit, KEY_CNT);
> + state->reset_seq_len = 0;
> state->reset_seq_cnt = 0;
>
> for (i = 0; i < sysrq_reset_seq_len; i++) {
[Severity: Medium]
Does clearing the reset_keybit here create a situation where the reset timer
becomes uncancelable if the sequence changes while keys are held?
If sysrq_reset_downtime_ms is configured and a user is currently holding the
reset sequence keys, the reset timer will be active. If the sequence is then
modified via sysfs, this function clears the old reset_keybit.
When the user subsequently releases the old keys:
drivers/tty/sysrq.c:sysrq_detect_reset_sequence() {
if (!test_bit(code, state->reset_keybit)) {
/* ... */
if (value && state->reset_seq_cnt) {
state->reset_canceled = true;
timer_delete(&state->keyreset_timer);
}
} else if (value == 0) {
...
}
Because the key is no longer in reset_keybit, it takes the first branch.
Since this is a key release (value == 0), the timer_delete() is skipped,
leaving the timer active and potentially causing an unwanted system reboot.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016032732.2328852-1-zhanxusheng@xiaomi.com?part=1
next prev parent reply other threads:[~2026-10-16 3:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 3:27 [PATCH] Input: sysrq - reset the per-device key state when reparsing reset_seq Zhan Xusheng
2026-10-16 3:41 ` sashiko-bot [this message]
2026-10-16 5:37 ` Greg Kroah-Hartman
2026-10-16 5:38 ` Greg Kroah-Hartman
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=sashiko-outbox-173692@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhanxusheng1024@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.