From: sashiko-bot@kernel.org
To: "Markus Probst" <markus.probst@posteo.de>
Cc: gary@garyguo.net, linux-serial@vger.kernel.org, ojeda@kernel.org
Subject: Re: [PATCH v2 1/3] tty: serdev: Export functions to pause receive_buf callback calls
Date: Sun, 20 Sep 2026 14:40:23 +0000 [thread overview]
Message-ID: <20260920144023.B874E1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260920-rust_serdev_probe_refactor-v2-1-43b855162f5d@posteo.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tty: missing hardware memory barrier after test_bit() on weakly ordered archs
--
commit 85ed03352c1176c6dcb07b7e3b1ab8aa8ce0db1d
Author: Markus Probst <markus.probst@posteo.de>
tty: serdev: Export functions to pause receive_buf callback calls
This commit introduces functions to pause and resume the receive_buf
callback in the serdev core. These changes are intended to simplify the
serdev Rust abstraction and help resolve race conditions in data
reception handling.
> diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
> index bab1b143b8a68..e8aa89e733bd8 100644
> --- a/drivers/tty/serdev/serdev-ttyport.c
> +++ b/drivers/tty/serdev/serdev-ttyport.c
> @@ -32,6 +34,14 @@ static size_t ttyport_receive_buf(struct tty_port *port, const u8 *cp,
> if (!test_bit(SERPORT_ACTIVE, &serport->flags))
> return 0;
>
> + if (test_bit(SERPORT_PAUSE_RX, &serport->flags))
> + return 0;
> +
> + /*
> + * Ensure writes by the driver are visible before allowing traffic to resume.
> + */
> + smp_mb__after_atomic();
> +
> ret = serdev_controller_receive_buf(ctrl, cp, count);
[Severity: High]
Does this fail to provide a hardware memory barrier after test_bit() on weakly
ordered architectures?
According to the kernel documentation for atomic bitops, test_bit() is a
non-RMW (read-modify-write) operation. The smp_mb__after_atomic() macro is
strictly intended for RMW operations.
On weakly ordered architectures where atomic RMWs are naturally ordered,
smp_mb__after_atomic() expands to a mere compiler barrier without emitting an
actual hardware fence. As a result, the CPU may be free to reorder the load of
SERPORT_PAUSE_RX with subsequent driver data loads inside
serdev_controller_receive_buf().
Could this reordering lead to the consumer observing stale buffer state,
potentially causing data corruption or dropped RX data?
Would it be more appropriate to use test_bit_acquire() or a full smp_mb() here
to establish the necessary acquire barrier?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920-rust_serdev_probe_refactor-v2-0-43b855162f5d@posteo.de?part=1
next prev parent reply other threads:[~2026-09-20 14:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 14:29 [PATCH v2 0/3] rust: serdev: Refactor Markus Probst
2026-09-20 14:29 ` [PATCH v2 1/3] tty: serdev: Export functions to pause receive_buf callback calls Markus Probst
2026-09-20 14:40 ` sashiko-bot [this message]
2026-09-23 10:36 ` Greg KH
2026-09-23 10:35 ` Greg Kroah-Hartman
2026-09-23 13:31 ` Markus Probst
2026-09-23 13:52 ` Gary Guo
2026-09-23 15:06 ` Markus Probst
2026-09-23 14:26 ` Greg Kroah-Hartman
2026-09-23 15:03 ` Markus Probst
2026-09-20 14:30 ` [PATCH v2 2/3] rust: serdev: Replace `active` mutex with receive pause Markus Probst
2026-09-20 14:39 ` sashiko-bot
2026-09-20 14:30 ` [PATCH v2 3/3] rust: serdev: Simplify callbacks Markus Probst
2026-09-20 14:44 ` 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=20260920144023.B874E1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-serial@vger.kernel.org \
--cc=markus.probst@posteo.de \
--cc=ojeda@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.