Same issue as the previous commit, on the receive side: uart_read()
advances recv.tail from thread context without holding the critical
section, but the recvbuf batch path of uart_recvchars() reads recv.tail
several times (the full check, the watermark count and the free-space
computation). If uart_read() moves and wraps the index in between, the
computed free space goes negative and is passed to recvbuf() as a huge
size_t, which lets the driver store past the end of the ring buffer.
Read recv.tail once per loop iteration and derive everything from that
snapshot. The consumer only ever moves the index forward, so a stale
snapshot merely stores less now.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
uart_putxmitchar() advances xmit.head from thread context without
holding the critical section, so on SMP the head index can move, and
wrap around, while uart_xmitchars() runs in the TX interrupt on another
CPU. Since commit b319c27f03 ("serial: Added APIs for receiving and
sending multiple chars") the sendbuf path of uart_xmitchars() reads
xmit.head twice: once to decide whether the pending data is contiguous
and again to compute its length. If the producer wraps the index in
between, the computed length goes negative, is passed to sendbuf() as a
huge size_t and the driver transmits memory far beyond the ring buffer.
The per-byte path reads the index only once and is not affected, which
is why this went unnoticed: the batch path is only used by drivers that
implement sendbuf, and the 16550 driver gained it in commit 45c38d8592
("drivers/serial/16550: add polling mode support for serial drivers").
qemu-intel64 with SMP is the first configuration combining a sendbuf
driver with a producer running on another CPU.
On qemu-intel64 SMP this shows up as an endless stream of NUL bytes on
the console (captured with gdb: head = 1, tail = 8, size = 16, and
u16550_sendbuf() called with size = (size_t)-7), which makes the ntfc
test harness fail every test that runs while the flood lasts.
Read the head index once per loop iteration and use that snapshot for
both the contiguity test and the length. The producer only ever moves
the index forward, so a stale snapshot merely sends less now.
Assisted-by: Claude Code
Signed-off-by: raiden00pl <raiden00@railab.me>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
When the receive buffer is full and the driver only implements recvbuf
operation without receive operation, the code would crash due to calling
a NULL function pointer. This patch fixes the issue by:
1. Check if recvbuf is available before calling it
2. When buffer is full, use a temporary buffer to drain hardware FIFO
to prevent data accumulation in hardware
3. Add proper NULL check for receive operation to avoid crash
4. Initialize pbuf to NULL to prevent uninitialized variable usage
This ensures the serial driver works correctly even when only recvbuf
is implemented and the receive buffer is full.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
When pressing Ctrl-C, the foreground process did not receive SIGINT
and failed to terminate.
The serial driver called nxsig_tgkill(-1, dev->pid, signo) from
interrupt context. With pid=-1, nxsig_dispatch() was called with
thread=true, which requires stcb->group == this_task()->group.
However, in interrupt context, this_task() returns the IDLE task,
whose group differs from the target process group. This caused
the signal dispatch to fail with -ESRCH.
Solution:
Replace nxsig_tgkill(-1, pid, signo) with nxsig_kill(pid, signo).
nxsig_kill() uses thread=false, which routes through group_signal()
without the same-group check, allowing signals to be delivered
correctly from interrupt context.
Impact:
- Fixes Ctrl-C signal delivery in serial console
- No API changes
- Affects serial driver interrupt handling only
Testing: Verified on QEMU ARM64 simulator with serial console
Signed-off-by: yinshengkai <yinshengkai@bytedance.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Follow the POSIX description.
SIGTSTP should be sent when the Ctrl-Z characters is encountered, not SIGSTP.
Testing:
Built with hifive1-revb:nsh (CONFIG_SERIAL_TERMIOS=y, CONFIG_SIG_DEFAULT=y and CONFIG_TTY_SIGTSTP=y)
drivers: serial: Fix data corruption when outputting data in SMP mode
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Approved-by: Gregory Nutt <gnutt@nuttx.org>
drivers/serial/Kconfig: It is no longer necessary to restrict Ctrl-C handling to the FLAT build
sched/signal: Add a new configuration option to select signal default actions, separate handling of signal default actions from both task startup logic and from the serial TTY Ctrl-C logic. Add a signal set in the group structure to keep track of what signals have been set to the default action. In dispatching signals in PROTECTED or KERNEL mode, use this signal set to determine if the default signal handler is attached and dispatch the signal in kernel mode for the default actions.
drivers/serial: Add Ctrl-C/Ctrl-X support. This is an initial working implementation that still requires that several details be resolved.
sched/task/task_start.c: Add default signal action to SIGKILL.
