Linux Input/HID development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 4/7] Input: gscps2 - serialize hardware and buffer access in gscps2_flush()
Date: Sun, 30 Aug 2026 21:02:30 +0000	[thread overview]
Message-ID: <20260830210231.1B06E1F01558@smtp.kernel.org> (raw)
In-Reply-To: <20260830-gscps2-v1-4-c733d4cae7f9@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] gscps2_writeb_output spins infinitely if the hardware receive buffer becomes full while executing in a context where IRQs are disabled.
--

commit 98b3bfa0449cf3b48806ab726d6170adf6e0246e
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

    Input: gscps2 - serialize hardware and buffer access in gscps2_flush()
    
    gscps2_flush() reads from hardware registers and resets the ring buffer
    indices ps2port->act and ps2port->append. In gscps2_enable(), the
    trailing gscps2_flush() was called without holding ps2port->lock, racing
    with concurrent hardware interrupts and buffer access.
    
    Assert that ps2port->lock is held in gscps2_flush() with
    lockdep_assert_held(), and ensure all callers acquire ps2port->lock so
    that multi-step hardware sequences remain fully serialized without
    unprotected windows.

> diff --git a/drivers/input/serio/gscps2.c b/drivers/input/serio/gscps2.c
> index fef6fffb6f865..36c25db9ff7f6 100644
> --- a/drivers/input/serio/gscps2.c
> +++ b/drivers/input/serio/gscps2.c
[ ... ]
> @@ -364,7 +366,8 @@ static void gscps2_enable(struct gscps2port *ps2port, bool enable)

[Severity: High]
This is a pre-existing issue, but can the loop in the preceding function
gscps2_writeb_output() spin infinitely and cause a hard lockup?

Looking at gscps2_writeb_output():

	while (gscps2_readb_status(addr) & GSC_STAT_RBNE)
		cpu_relax();

This lockless loop waits for a status flag to clear without a timeout or
fallback wake mechanism. If a byte arrives from the PS/2 port (setting
GSC_STAT_RBNE) while gscps2_writeb_output() is executing with local
interrupts disabled, the gscps2_interrupt handler cannot run on the same CPU
to drain the buffer.

Could this spin forever if triggered by normal hardware interaction, such as
typing on the keyboard while the system sends a command?

>  	}
>  
>  	wait_TBE(ps2port->addr);
> -	gscps2_flush(ps2port);
> +	scoped_guard(spinlock_irqsave, &ps2port->lock)
> +		gscps2_flush(ps2port);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260830-gscps2-v1-0-c733d4cae7f9@gmail.com?part=4

  reply	other threads:[~2026-08-30 21:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 20:52 [PATCH 0/7] Input: gscps2: cleanups and locking fixes Dmitry Torokhov
2026-08-30 20:52 ` [PATCH 1/7] Input: gscps2 - clean up driver code style and structure Dmitry Torokhov
2026-08-30 21:04   ` sashiko-bot
2026-08-30 20:52 ` [PATCH 2/7] Input: gscps2 - use RCU for ps2port_list and manage it in open/close Dmitry Torokhov
2026-08-30 20:52 ` [PATCH 3/7] Input: gscps2 - protect buffer access in read and report helpers Dmitry Torokhov
2026-08-30 21:05   ` sashiko-bot
2026-08-30 20:52 ` [PATCH 4/7] Input: gscps2 - serialize hardware and buffer access in gscps2_flush() Dmitry Torokhov
2026-08-30 21:02   ` sashiko-bot [this message]
2026-08-30 20:52 ` [PATCH 5/7] Input: gscps2 - return IRQ_NONE when interrupt is not handled Dmitry Torokhov
2026-08-30 21:05   ` sashiko-bot
2026-08-30 20:52 ` [PATCH 6/7] Input: gscps2 - serialize concurrent interrupt handlers Dmitry Torokhov
2026-08-30 21:07   ` sashiko-bot
2026-08-30 20:52 ` [PATCH 7/7] Input: gscps2 - drop busy-wait and manual interrupt pump on transmit Dmitry Torokhov
2026-08-30 21:05   ` 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=20260830210231.1B06E1F01558@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox