From: sashiko-bot@kernel.org
To: "Jaidev Shastri" <jaidevshastri@vt.edu>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH 1/6] vt: keyboard: publish shift_state with release semantics
Date: Tue, 22 Sep 2026 01:38:30 +0000 [thread overview]
Message-ID: <20260922013831.257961F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921-mb-keyboard-v1-1-d170228b80c0@vt.edu>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] vt: unnecessary memory barriers for lockless scalar access
--
commit 97a82ad73b6718204026d341ed2e3831f7cbd52f
Author: Jaidev Shastri <jaidevshastri@vt.edu>
vt: keyboard: publish shift_state with release semantics
This commit replaces plain reads and writes of shift_state with
smp_load_acquire() and smp_store_release() to specify the relation
between the counters and the summary word.
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index c41d850b29c6e..089f3b048beee 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
[ ... ]
> @@ -889,9 +890,11 @@ static void k_shift(struct vc_data *vc, unsigned char value, char up_flag)
> shift_down[value]++;
>
> if (shift_down[value])
> - shift_state |= BIT(value);
> + state = shift_state | BIT(value);
> else
> - shift_state &= ~BIT(value);
> + state = shift_state & ~BIT(value);
> + /* Pairs with the smp_load_acquire() in vt_get_shift_state(). */
> + smp_store_release(&shift_state, state);
[Severity: Low]
Are acquire/release semantics strictly necessary here?
The only lockless reader is vt_get_shift_state(), which simply returns
shift_state directly to userspace when it calls the TIOCL_GETSHIFTSTATE ioctl.
It does not read any dependent memory like the shift_down[] counters.
Without dependent memory reads to sequence after the flag read, the memory
ordering guarantees provided by acquire/release semantics seem unused,
adding memory barrier overhead to every shift key press and release.
Would a simple WRITE_ONCE() here and READ_ONCE() in vt_get_shift_state()
be sufficient to prevent compiler tearing and reordering for this single
scalar value?
>
> /* kludge */
> if (up_flag && shift_state != old_state && npadch_active) {
[ ... ]
> @@ -2212,8 +2215,11 @@ void vt_reset_unicode(unsigned int console)
> */
> int vt_get_shift_state(void)
> {
> - /* Don't lock as this is a transient report */
> - return shift_state;
> + /*
> + * Don't lock as this is a transient report. Pairs with the
> + * smp_store_release() in k_shift().
> + */
> + return smp_load_acquire(&shift_state);
[Severity: Low]
Could this use a plain READ_ONCE() instead of smp_load_acquire() since
it does not read any dependent memory?
> }
>
> /**
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-mb-keyboard-v1-0-d170228b80c0@vt.edu?part=1
next prev parent reply other threads:[~2026-09-22 1:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 1:28 [PATCH 0/6] vt: keyboard: make the kbd_event_lock ordering explicit Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:28 ` [PATCH 1/6] vt: keyboard: publish shift_state with release semantics Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:38 ` sashiko-bot [this message]
2026-09-23 12:51 ` Greg Kroah-Hartman
2026-09-22 1:28 ` [PATCH 2/6] vt: keyboard: publish npadch_value " Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:39 ` sashiko-bot
2026-09-22 1:28 ` [PATCH 3/6] vt: keyboard: publish dead_key_next " Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:39 ` sashiko-bot
2026-09-22 1:28 ` [PATCH 4/6] vt: keyboard: publish accent_table_size " Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:36 ` sashiko-bot
2026-09-22 1:28 ` [PATCH 5/6] vt: keyboard: recompute the shift state into locals before publishing it Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:34 ` sashiko-bot
2026-09-22 1:28 ` [PATCH 6/6] vt: keyboard: publish the shift_down[] counters with release semantics Jaidev Shastri via B4 Relay
2026-09-22 1:28 ` Jaidev Shastri
2026-09-22 1:42 ` 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=20260922013831.257961F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jaidevshastri@vt.edu \
--cc=linux-serial@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.