* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Geert Uytterhoeven @ 2026-01-27 12:02 UTC (permalink / raw)
To: Tommaso Merciai
Cc: Marek Szyprowski, Xin Zhao, gregkh, jirislaby, tj, hch,
linux-kernel, linux-serial, Linux-Renesas
In-Reply-To: <aXic3pyl0xfTSYB-@tom-desktop>
On Tue, 27 Jan 2026 at 12:10, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> On Tue, Jan 27, 2026 at 11:34:32AM +0100, Marek Szyprowski wrote:
> > On 23.12.2025 04:48, Xin Zhao wrote:
> > > On the embedded platform, certain critical data, such as IMU data, is
> > > transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> > > layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> > > Although the unbound workqueue can create new threads on demand and wake
> > > up the kworker thread on an idle CPU, it may be preempted by real-time
> > > tasks or other high-prio tasks.
> > >
> > > flush_to_ldisc() needs to wake up the relevant data handle thread. When
> > > executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> > > does not disable preemption but disables migration in RT-Linux. This
> > > prevents the kworker thread from being migrated to other cores by CPU's
> > > balancing logic, resulting in long delays. The call trace is as follows:
> > > __wake_up_common_lock
> > > __wake_up
> > > ep_poll_callback
> > > __wake_up_common
> > > __wake_up_common_lock
> > > __wake_up
> > > n_tty_receive_buf_common
> > > n_tty_receive_buf2
> > > tty_ldisc_receive_buf
> > > tty_port_default_receive_buf
> > > flush_to_ldisc
> > >
> > > In our system, the processing interval for each frame of IMU data
> > > transmitted via UART can experience significant jitter due to this issue.
> > > Instead of the expected 10 to 15 ms frame processing interval, we see
> > > spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
> > > be 2 to 3 occurrences of such high jitter, which is quite frequent. This
> > > jitter exceeds the software's tolerable limit of 20 ms.
> > >
> > > Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
> > > default linked to default workqueue allocated when tty_register_driver().
> > > The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
> > > nice can be set dynamically. The execution timing of tty_port_link_wq() is
> > > not clearly restricted. The newly added function tty_port_link_driver_wq()
> > > checks whether the flip_wq of the tty_port has already been assigned when
> > > linking the default tty_driver's workqueue to the port. After the user has
> > > set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
> > > system will only use this custom workqueue, even if tty_driver does not
> > > have %TTY_DRIVER_CUSTOM_WORKQUEUE flag.
> > >
> > > Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the
> > > default single tty_driver workqueue. Two reasons why need to introduce the
> > > %TTY_DRIVER_CUSTOM_WORKQUEUE flag:
> > > 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
> > > fail when trying to create a workqueue with the same name. The pty is an
> > > example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
> > > enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
> > > 2. Different tty ports may be used for different tasks, which may require
> > > separate core binding control via workqueues. In this case, the workqueue
> > > created by default in the tty driver is unnecessary. Enabling this flag
> > > prevents the creation of this redundant workqueue.
> > >
> > > After applying this patch, we can set the related UART TTY flip buffer
> > > workqueue by sysfs. We set the cpumask to CPU cores associated with the
> > > IMU tasks, and set the nice to -20. Testing has shown significant
> > > improvement in the previously described issue, with almost no stuttering
> > > occurring anymore.
> > >
> > > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> >
> > This patch landed in linux-next as commit d000422a46aa ("tty: tty_port:
> > add workqueue to flip TTY buffer"). In my tests I found that it causes
> > some regressions, see the comments in the code below.
>
> Same here, testing on RZ/G3E looks like s2idle is broken:
> [ 185.237717] Call trace:
> [ 185.240176] __queue_work+0x20/0x474 (P)
> [ 185.244141] queue_work_on+0x8c/0xa8
> [ 185.247753] tty_flip_buffer_push+0x2c/0x38
Lucky you, there is a hint to tty in your trace ;-)
I see a similar crash during boot on koelsch (R-Car M2-W), and a
lock-up during boot on salvator-xs (R-Car H3 ES2.0), with either no
output or an rcu stall:
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 1-...!: (0 ticks this GP) idle=1fe8/0/0x0 softirq=85/85
fqs=1 (false positive?)
rcu: 2-...!: (1 ticks this GP) idle=1c78/0/0x0 softirq=77/77
fqs=1 (false positive?)
rcu: 6-...!: (0 ticks this GP) idle=07b8/0/0x0 softirq=9/9
fqs=1 (false positive?)
rcu: (detected by 3, t=5260 jiffies, g=-1015, q=274 ncpus=8)
Sending NMI from CPU 3 to CPUs 1:
Sending NMI from CPU 3 to CPUs 2:
Sending NMI from CPU 3 to CPUs 6:
rcu: rcu_preempt kthread timer wakeup didn't happen for 12771
jiffies! g-1015 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x200
rcu: Possible timer handling issue on cpu=6 timer-softirq=1
rcu: rcu_preempt kthread starved for 12780 jiffies! g-1015 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=6
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM
is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R stack:0 pid:15 tgid:15
ppid:2 task_flags:0x208040 flags:0x00000010
Call trace:
__switch_to+0xcc/0x100 (T)
__schedule+0x368/0xc00
schedule+0x30/0x100
schedule_timeout+0x80/0xf8
rcu_gp_fqs_loop+0xfc/0x418
rcu_gp_kthread+0xe0/0xf4
kthread+0x128/0x1e0
ret_from_fork+0x10/0x20
Reverting commit d000422a46aad322 ("tty: tty_port: add workqueue to
flip TTY buffer") in tty-next fixes both.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Tommaso Merciai @ 2026-01-27 11:09 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Xin Zhao, gregkh, jirislaby, tj, hch, linux-kernel, linux-serial
In-Reply-To: <d1942304-ee30-478d-90fb-279519f3ae81@samsung.com>
Hi Marek, All,
Thanks for your comment.
On Tue, Jan 27, 2026 at 11:34:32AM +0100, Marek Szyprowski wrote:
> On 23.12.2025 04:48, Xin Zhao wrote:
> > On the embedded platform, certain critical data, such as IMU data, is
> > transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> > layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> > Although the unbound workqueue can create new threads on demand and wake
> > up the kworker thread on an idle CPU, it may be preempted by real-time
> > tasks or other high-prio tasks.
> >
> > flush_to_ldisc() needs to wake up the relevant data handle thread. When
> > executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> > does not disable preemption but disables migration in RT-Linux. This
> > prevents the kworker thread from being migrated to other cores by CPU's
> > balancing logic, resulting in long delays. The call trace is as follows:
> > __wake_up_common_lock
> > __wake_up
> > ep_poll_callback
> > __wake_up_common
> > __wake_up_common_lock
> > __wake_up
> > n_tty_receive_buf_common
> > n_tty_receive_buf2
> > tty_ldisc_receive_buf
> > tty_port_default_receive_buf
> > flush_to_ldisc
> >
> > In our system, the processing interval for each frame of IMU data
> > transmitted via UART can experience significant jitter due to this issue.
> > Instead of the expected 10 to 15 ms frame processing interval, we see
> > spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
> > be 2 to 3 occurrences of such high jitter, which is quite frequent. This
> > jitter exceeds the software's tolerable limit of 20 ms.
> >
> > Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
> > default linked to default workqueue allocated when tty_register_driver().
> > The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
> > nice can be set dynamically. The execution timing of tty_port_link_wq() is
> > not clearly restricted. The newly added function tty_port_link_driver_wq()
> > checks whether the flip_wq of the tty_port has already been assigned when
> > linking the default tty_driver's workqueue to the port. After the user has
> > set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
> > system will only use this custom workqueue, even if tty_driver does not
> > have %TTY_DRIVER_CUSTOM_WORKQUEUE flag.
> >
> > Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the
> > default single tty_driver workqueue. Two reasons why need to introduce the
> > %TTY_DRIVER_CUSTOM_WORKQUEUE flag:
> > 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
> > fail when trying to create a workqueue with the same name. The pty is an
> > example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
> > enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
> > 2. Different tty ports may be used for different tasks, which may require
> > separate core binding control via workqueues. In this case, the workqueue
> > created by default in the tty driver is unnecessary. Enabling this flag
> > prevents the creation of this redundant workqueue.
> >
> > After applying this patch, we can set the related UART TTY flip buffer
> > workqueue by sysfs. We set the cpumask to CPU cores associated with the
> > IMU tasks, and set the nice to -20. Testing has shown significant
> > improvement in the previously described issue, with almost no stuttering
> > occurring anymore.
> >
> > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
>
> This patch landed in linux-next as commit d000422a46aa ("tty: tty_port:
> add workqueue to flip TTY buffer"). In my tests I found that it causes
> some regressions, see the comments in the code below.
Same here, testing on RZ/G3E looks like s2idle is broken:
root@smarc-rzg3e:~# echo s2idle > /sys/power/mem_sleep
eroot@smarc-rzg3e:~# echo mem > /sys/power/state
[ 182.263395] PM: suspend entry (s2idle)
[ 182.267619] Filesystems sync: 0.000 seconds
[ 182.275175] Freezing user space processes
[ 182.282334] Freezing user space processes completed (elapsed 0.002 seconds)
[ 182.289447] OOM killer disabled.
[ 182.292771] Freezing remaining freezable tasks
[ 182.299126] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 182.369910] renesas-gbeth 15c30000.ethernet end0: Link is Down
[ 182.379217] PM: suspend devices took 0.076 seconds
[ 185.039929] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000100
[ 185.048725] Mem abort info:
[ 185.051530] ESR = 0x0000000096000004
[ 185.055288] EC = 0x25: DABT (current EL), IL = 32 bits
[ 185.060608] SET = 0, FnV = 0
[ 185.063674] EA = 0, S1PTW = 0
[ 185.066825] FSC = 0x04: level 0 translation fault
[ 185.071708] Data abort info:
[ 185.074593] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 185.080079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 185.085136] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 185.090455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102465000
[ 185.096900] [0000000000000100] pgd=0000000000000000, p4d=0000000000000000
[ 185.103723] Internal error: Oops: 0000000096000004 [#1] SMP
[ 185.109389] Modules linked in: sha256 cfg80211 panfrost drm_shmem_helper bluetooth gpu_sched spi_rpc_if rcar_canfd drm_kms_helper can_dev rtc_isl1208 phy_rzg3e_usb3 ecdh_generic renesas_r
pc_if ecc rfkill fuse drm backlight ipv6
[ 185.129854] CPU: 0 UID: 0 PID: 384 Comm: sh Not tainted 6.19.0-rc7-next-20260126-00006-gdc83ac04b66e #306 PREEMPT
[ 185.140207] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)
[ 185.147683] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 185.154656] pc : __queue_work+0x20/0x474
[ 185.158621] lr : queue_work_on+0x8c/0xa8
[ 185.162571] sp : ffff80008314bbd0
[ 185.165896] x29: ffff80008314bbd0 x28: ffff800082f74268 x27: 0000000000000000
[ 185.173083] x26: 0000000000000000 x25: ffff0000cbdf8400 x24: 0000000000000000
[ 185.180264] x23: 0000000000000200 x22: 00000000000000c0 x21: 0000000000000000
[ 185.187446] x20: 0000000000000000 x19: ffff0000cbdf8410 x18: 0000000000000001
[ 185.194629] x17: ffff8000797a8000 x16: ffff800083148000 x15: 00000dad54b1bae4
[ 185.201812] x14: 0000000000000000 x13: 0000000000000010 x12: 0000000000000010
[ 185.208992] x11: 0000000000000040 x10: 0000000000000031 x9 : ffff0000c0030be8
[ 185.216173] x8 : 0000000000000031 x7 : 72ecc8f68fa27bc6 x6 : 0000000000000031
[ 185.223353] x5 : ffff0000cbdfb421 x4 : ffff0000cbdf8410 x3 : 0000000000000000
[ 185.230534] x2 : ffff0000cbdf8410 x1 : 0000000000000000 x0 : 0000000000000200
[ 185.237717] Call trace:
[ 185.240176] __queue_work+0x20/0x474 (P)
[ 185.244141] queue_work_on+0x8c/0xa8
[ 185.247753] tty_flip_buffer_push+0x2c/0x38
[ 185.251987] put_queue+0x64/0xc0
[ 185.255261] k_unicode.part.0+0x84/0xc4
[ 185.259141] k_self+0x30/0x40
[ 185.262154] kbd_event+0x304/0x59c
[ 185.265601] input_handle_events_default+0x4c/0x70
[ 185.270437] input_pass_values+0x130/0x150
[ 185.274577] input_event_dispose+0x134/0x138
[ 185.278889] input_handle_event+0x58/0x84
[ 185.282929] input_event+0x64/0xa4
[ 185.286362] gpio_keys_irq_isr+0x78/0x130
[ 185.290414] __handle_irq_event_percpu+0x44/0x1d8
[ 185.295160] handle_irq_event+0x4c/0xac
[ 185.299035] handle_fasteoi_irq+0x104/0x194
[ 185.303246] handle_irq_desc+0x40/0x58
[ 185.307033] generic_handle_domain_irq+0x18/0x24
[ 185.311686] gic_handle_irq+0x4c/0x10c
[ 185.315465] call_on_irq_stack+0x30/0x48
[ 185.319423] do_interrupt_handler+0x80/0x84
[ 185.323645] el1_interrupt+0x3c/0x60
[ 185.327265] el1h_64_irq_handler+0x18/0x24
[ 185.331404] el1h_64_irq+0x6c/0x70
[ 185.334838] _raw_spin_unlock_irqrestore+0x8/0x44 (P)
[ 185.339931] resume_device_irqs+0x14/0x20
[ 185.343983] dpm_resume_noirq+0x14/0x24
[ 185.347860] suspend_devices_and_enter+0x674/0x738
[ 185.352684] pm_suspend+0x1f0/0x2b4
[ 185.356207] state_store+0x80/0xec
[ 185.359641] kobj_attr_store+0x18/0x2c
[ 185.363423] sysfs_kf_write+0x7c/0x94
[ 185.367122] kernfs_fop_write_iter+0x130/0x1dc
[ 185.371596] vfs_write+0x240/0x370
[ 185.375038] ksys_write+0x70/0x108
[ 185.378479] __arm64_sys_write+0x1c/0x28
[ 185.382438] invoke_syscall+0x48/0x10c
[ 185.386237] el0_svc_common.constprop.0+0xc0/0xe0
[ 185.390986] do_el0_svc+0x1c/0x28
[ 185.394350] el0_svc+0x34/0x108
[ 185.397535] el0t_64_sync_handler+0xa0/0xe4
[ 185.401761] el0t_64_sync+0x198/0x19c
[ 185.405475] Code: aa0103f4 aa0203f3 a90363f7 2a0003f7 (b9410020)
[ 185.411571] ---[ end trace 0000000000000000 ]---
[ 185.416200] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 185.423072] SMP: stopping secondary CPUs
[ 185.427031] Kernel Offset: disabled
[ 185.430525] CPU features: 0x1000000,00080005,00230501,0400721b
[ 185.436365] Memory Limit: none
[ 185.439435] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
Reverting this I'm able to see s2idle work back.
Hope this help.
Thank you!
Kind Regards,
Tommaso
>
> > ---
> >
> > Change in v8:
> > - Rebase code, use system_dfl_wq instead of system_unbound_wq.
> >
> > Change in v7:
> > - Pty simply link to system_unbound_wq instead of allocating a custom one,
> > as suggested by Jiri Slaby.
> > - Modify some inappropriate expressions in the code comments,
> > as suggested by Jiri Slaby.
> > - Link to v7: https://lore.kernel.org/all/20251210125028.4174917-1-jackzxcui1989@163.com/T/#u
> >
> > Change in v6:
> > - Modify many inappropriate expressions in the commit log and code comments,
> > as suggested by Jiri Slaby.
> > - Add reasons why need to introduce the %TTY_DRIVER_CUSTOM_WORKQUEUE in
> > commit log.
> > - Modify the error handling related to the allocation failure of workqueue in
> > tty_register_driver(), as suggested by Jiri Slaby.
> > - Add description of tty_port_link_driver_wq() in the commit log,
> > as suggested by Jiri Slaby.
> > - Link to v6: https://lore.kernel.org/all/20251210031827.3771327-1-jackzxcui1989@163.com/
> >
> > Change in v5:
> > - Do not allocate workqueue twice when CONFIG_UNIX98_PTYS and
> > CONFIG_LEGACY_PTYS are all enabled.
> > - Link to v5: https://lore.kernel.org/all/20251205030829.1829987-1-jackzxcui1989@163.com/
> >
> > Change in v4:
> > - Simplify the logic for creating and releasing the workqueue,
> > as suggested by Tejun Heo.
> > - Allocate single workqueue of one tty_driver as default, link it to
> > port when tty_port register device or tty_driver.
> > - Introduce tty_port_link_wq() to link specific workqueue to port.
> > - Add driver flag %TTY_DRIVER_CUSTOM_WORKQUEUE meaning not to create the
> > default single tty_driver workqueue.
> > - Link to v4: https://lore.kernel.org/all/202512041303.7192024b-lkp@intel.com/T/#t
> >
> > Change in v3:
> > - Add tty flip workqueue for all tty ports, as suggested by Greg KH.
> > Every tty port use an individual flip workqueue, while all pty ports
> > share the same workqueue created in pty_flip_wq_init().
> > - Modify the commit log to describe the reason for latency spikes in
> > RT-Linux.
> > - Link to v3: https://lore.kernel.org/all/20251027060929.394053-1-jackzxcui1989@163.com/
> >
> > Change in v2:
> > - Do not add new module parameters
> > as suggested by Greg KH
> > - Set WQ_SYSFS to allow properties changes from userspace
> > as suggested by Tejun Heo
> > - Link to v2: https://lore.kernel.org/all/20251024155534.2302590-1-jackzxcui1989@163.com
> > ---
> > drivers/tty/pty.c | 14 ++++++++++----
> > drivers/tty/tty_buffer.c | 8 ++++----
> > drivers/tty/tty_io.c | 21 ++++++++++++++++++++-
> > drivers/tty/tty_port.c | 23 +++++++++++++++++++++++
> > include/linux/tty_buffer.h | 1 +
> > include/linux/tty_driver.h | 7 +++++++
> > include/linux/tty_port.h | 13 +++++++++++++
> > 7 files changed, 78 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> > index 6120d827a..1f17575f8 100644
> > --- a/drivers/tty/pty.c
> > +++ b/drivers/tty/pty.c
> > @@ -403,6 +403,8 @@ static int pty_common_install(struct tty_driver *driver, struct tty_struct *tty,
> > o_tty->link = tty;
> > tty_port_init(ports[0]);
> > tty_port_init(ports[1]);
> > + tty_port_link_wq(ports[0], system_dfl_wq);
> > + tty_port_link_wq(ports[1], system_dfl_wq);
> > tty_buffer_set_limit(ports[0], 8192);
> > tty_buffer_set_limit(ports[1], 8192);
> > o_tty->port = ports[0];
> > @@ -532,14 +534,16 @@ static void __init legacy_pty_init(void)
> > pty_driver = tty_alloc_driver(legacy_count,
> > TTY_DRIVER_RESET_TERMIOS |
> > TTY_DRIVER_REAL_RAW |
> > - TTY_DRIVER_DYNAMIC_ALLOC);
> > + TTY_DRIVER_DYNAMIC_ALLOC |
> > + TTY_DRIVER_CUSTOM_WORKQUEUE);
> > if (IS_ERR(pty_driver))
> > panic("Couldn't allocate pty driver");
> >
> > pty_slave_driver = tty_alloc_driver(legacy_count,
> > TTY_DRIVER_RESET_TERMIOS |
> > TTY_DRIVER_REAL_RAW |
> > - TTY_DRIVER_DYNAMIC_ALLOC);
> > + TTY_DRIVER_DYNAMIC_ALLOC |
> > + TTY_DRIVER_CUSTOM_WORKQUEUE);
> > if (IS_ERR(pty_slave_driver))
> > panic("Couldn't allocate pty slave driver");
> >
> > @@ -849,7 +853,8 @@ static void __init unix98_pty_init(void)
> > TTY_DRIVER_REAL_RAW |
> > TTY_DRIVER_DYNAMIC_DEV |
> > TTY_DRIVER_DEVPTS_MEM |
> > - TTY_DRIVER_DYNAMIC_ALLOC);
> > + TTY_DRIVER_DYNAMIC_ALLOC |
> > + TTY_DRIVER_CUSTOM_WORKQUEUE);
> > if (IS_ERR(ptm_driver))
> > panic("Couldn't allocate Unix98 ptm driver");
> > pts_driver = tty_alloc_driver(NR_UNIX98_PTY_MAX,
> > @@ -857,7 +862,8 @@ static void __init unix98_pty_init(void)
> > TTY_DRIVER_REAL_RAW |
> > TTY_DRIVER_DYNAMIC_DEV |
> > TTY_DRIVER_DEVPTS_MEM |
> > - TTY_DRIVER_DYNAMIC_ALLOC);
> > + TTY_DRIVER_DYNAMIC_ALLOC |
> > + TTY_DRIVER_CUSTOM_WORKQUEUE);
> > if (IS_ERR(pts_driver))
> > panic("Couldn't allocate Unix98 pts driver");
> >
> > diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> > index 1a5673acd..86e1e7178 100644
> > --- a/drivers/tty/tty_buffer.c
> > +++ b/drivers/tty/tty_buffer.c
> > @@ -76,7 +76,7 @@ void tty_buffer_unlock_exclusive(struct tty_port *port)
> > mutex_unlock(&buf->lock);
> >
> > if (restart)
> > - queue_work(system_dfl_wq, &buf->work);
> > + queue_work(buf->flip_wq, &buf->work);
> > }
> > EXPORT_SYMBOL_GPL(tty_buffer_unlock_exclusive);
> >
> > @@ -530,7 +530,7 @@ void tty_flip_buffer_push(struct tty_port *port)
> > struct tty_bufhead *buf = &port->buf;
> >
> > tty_flip_buffer_commit(buf->tail);
> > - queue_work(system_dfl_wq, &buf->work);
> > + queue_work(buf->flip_wq, &buf->work);
> > }
> > EXPORT_SYMBOL(tty_flip_buffer_push);
> >
> > @@ -560,7 +560,7 @@ int tty_insert_flip_string_and_push_buffer(struct tty_port *port,
> > tty_flip_buffer_commit(buf->tail);
> > spin_unlock_irqrestore(&port->lock, flags);
> >
> > - queue_work(system_dfl_wq, &buf->work);
> > + queue_work(buf->flip_wq, &buf->work);
> >
> > return size;
> > }
> > @@ -613,7 +613,7 @@ void tty_buffer_set_lock_subclass(struct tty_port *port)
> >
> > bool tty_buffer_restart_work(struct tty_port *port)
> > {
> > - return queue_work(system_dfl_wq, &port->buf.work);
> > + return queue_work(port->buf.flip_wq, &port->buf.work);
> > }
> >
> > bool tty_buffer_cancel_work(struct tty_port *port)
> > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> > index e2d92cf70..d64fb08ba 100644
> > --- a/drivers/tty/tty_io.c
> > +++ b/drivers/tty/tty_io.c
> > @@ -3446,10 +3446,23 @@ int tty_register_driver(struct tty_driver *driver)
> > if (error < 0)
> > goto err;
> >
> > + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE)) {
> > + driver->flip_wq = alloc_workqueue("%s-flip-wq", WQ_UNBOUND | WQ_SYSFS,
> > + 0, driver->name);
>
> It looks that driver->name is not unique on some systems, see:
>
> $ git grep ttyMSM drivers/tty/
> drivers/tty/serial/msm_serial.c: .name = "ttyMSM",
> drivers/tty/serial/msm_serial.c: .dev_name = "ttyMSM",
> drivers/tty/serial/qcom_geni_serial.c: .name = "ttyMSM",
> drivers/tty/serial/qcom_geni_serial.c: .dev_name = "ttyMSM",
>
> This fails on Qualcomm RB5 boards, breaking the boot process (booting
> hangs, because drivers try to use the unregistered wq):
>
> sysfs: cannot create duplicate filename
> '/devices/virtual/workqueue/ttyMSM-flip-wq'
> CPU: 6 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 6.19.0-rc7-next-20260126+ #16440 PREEMPT
> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
> Call trace:
> show_stack+0x18/0x24 (C)
> dump_stack_lvl+0xc0/0xd0
> dump_stack+0x18/0x24
> sysfs_warn_dup+0x64/0x80
> sysfs_create_dir_ns+0xe8/0x108
> kobject_add_internal+0x98/0x270
> kobject_add+0x94/0x10c
> device_add+0xec/0x720
> device_register+0x20/0x30
> workqueue_sysfs_register+0x8c/0x170
> __alloc_workqueue+0x554/0x668
> alloc_workqueue_noprof+0x5c/0xfc
> tty_register_driver+0x120/0x2d0
> uart_register_driver+0x120/0x1b0
> qcom_geni_serial_init+0x20/0xc8
> do_one_initcall+0x64/0x308
> kernel_init_freeable+0x284/0x508
> kernel_init+0x24/0x1dc
> ret_from_fork+0x10/0x20
> kobject: kobject_add_internal failed for ttyMSM-flip-wq with -EEXIST,
> don't try to register things with the same name in the same directory.
>
> Changing the above alloc_workqueue() to use 'driver->driver_name' fixes
> the boot issue. If keeping the driver->name is desired, then maybe the
> '"%s-%s-flip-wq", ..., driver->name, driver->driver_name' format is a
> better one.
>
> The other issue with this patch I've observed on ARM Juno R1 board. With
> one of the above fixes for the workqueue name, the boot process is still
> broken because of the NULL pointer dereference:
>
> input: gpio-keys as /de ** replaying previous printk message ** input:
> gpio-keys as /devices/platform/gpio-keys/input/input3 Unable to handle
> kernel NULL pointer dereference at virtual address 00000000000001c0 Mem
> abort info: ... [00000000000001c0] user address but active_mm is swapper
> Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU:
> 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-rc7-next-20260126+
> #16443 PREEMPT Hardware name: ARM Juno development board (r1) (DT)
> pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
> __queue_work+0x30/0x7c4 lr : queue_work_on+0xac/0xdc ... Call trace:
> __queue_work+0x30/0x7c4 (P) queue_work_on+0xac/0xdc
> tty_flip_buffer_push+0x2c/0x38 k_fn.part.0+0x7c/0xc8 k_fn+0x20/0x2c
> kbd_event+0x2d8/0x504 input_handle_events_default+0x50/0x74
> input_pass_values+0x148/0x2b4 input_handle_event+0xcc/0x5e0
> input_event+0x64/0xa4 gpio_keys_open+0x9c/0xc4
> input_open_device+0x8c/0x128 kbd_connect+0x84/0xa0
> input_attach_handler+0x9c/0xf4 input_register_device+0x308/0x48c
> gpio_keys_probe+0x40c/0xafc platform_probe+0x5c/0xac
> really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c
> driver_probe_device+0xdc/0x164 __driver_attach+0xe4/0x224
> bus_for_each_dev+0x74/0xd0 driver_attach+0x24/0x30
> bus_add_driver+0xe4/0x208 driver_register+0x60/0x128
> __platform_driver_register+0x24/0x30 gpio_keys_init+0x1c/0x28
> do_one_initcall+0x64/0x308 kernel_init_freeable+0x284/0x508
> kernel_init+0x24/0x1dc ret_from_fork+0x10/0x20 Code: a9025bf5 a90573fb
> aa0203fb 35001843 (b941c260) ---[ end trace 0000000000000000 ]--- note:
> swapper/0[1] exited with irqs disabled note: swapper/0[1] exited with
> preempt_count 3 Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b SMP: stopping secondary CPUs Kernel Offset: disabled
> CPU features: 0x1040000,41858004,00020000,0400421b Memory Limit: none
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b ]---
>
> Reverting $subject on top of current linux-next fixes this issue.
>
> > + if (!driver->flip_wq) {
> > + error = -ENOMEM;
> > + goto err_unreg_char;
> > + }
> > + for (i = 0; i < driver->num; i++) {
> > + if (driver->ports[i])
> > + tty_port_link_driver_wq(driver->ports[i], driver);
> > + }
> > + }
> > +
> > if (driver->flags & TTY_DRIVER_DYNAMIC_ALLOC) {
> > error = tty_cdev_add(driver, dev, 0, driver->num);
> > if (error)
> > - goto err_unreg_char;
> > + goto err_destroy_wq;
> > }
> >
> > scoped_guard(mutex, &tty_mutex)
> > @@ -3475,6 +3488,10 @@ int tty_register_driver(struct tty_driver *driver)
> > scoped_guard(mutex, &tty_mutex)
> > list_del(&driver->tty_drivers);
> >
> > +err_destroy_wq:
> > + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE))
> > + destroy_workqueue(driver->flip_wq);
> > +
> > err_unreg_char:
> > unregister_chrdev_region(dev, driver->num);
> > err:
> > @@ -3494,6 +3511,8 @@ void tty_unregister_driver(struct tty_driver *driver)
> > driver->num);
> > scoped_guard(mutex, &tty_mutex)
> > list_del(&driver->tty_drivers);
> > + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE))
> > + destroy_workqueue(driver->flip_wq);
> > }
> > EXPORT_SYMBOL(tty_unregister_driver);
> >
> > diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
> > index fe67c5cb0..611f87814 100644
> > --- a/drivers/tty/tty_port.c
> > +++ b/drivers/tty/tty_port.c
> > @@ -99,6 +99,26 @@ void tty_port_init(struct tty_port *port)
> > }
> > EXPORT_SYMBOL(tty_port_init);
> >
> > +/**
> > + * tty_port_link_wq - link tty_port and flip workqueue
> > + * @port: tty_port of the device
> > + * @flip_wq: workqueue to queue flip buffer work on
> > + *
> > + * When %TTY_DRIVER_CUSTOM_WORKQUEUE is used, every tty_port shall be linked to
> > + * a workqueue manually by this function, otherwise tty_flip_buffer_push() will
> > + * see %NULL flip_wq pointer on queue_work.
> > + * When %TTY_DRIVER_CUSTOM_WORKQUEUE is NOT used, the function can be used to
> > + * link a certain port to a specific workqueue, instead of using the workqueue
> > + * allocated in tty_register_driver().
> > + *
> > + * Note that TTY port API will NOT destroy the workqueue.
> > + */
> > +void tty_port_link_wq(struct tty_port *port, struct workqueue_struct *flip_wq)
> > +{
> > + port->buf.flip_wq = flip_wq;
> > +}
> > +EXPORT_SYMBOL_GPL(tty_port_link_wq);
> > +
> > /**
> > * tty_port_link_device - link tty and tty_port
> > * @port: tty_port of the device
> > @@ -157,6 +177,7 @@ struct device *tty_port_register_device_attr(struct tty_port *port,
> > const struct attribute_group **attr_grp)
> > {
> > tty_port_link_device(port, driver, index);
> > + tty_port_link_driver_wq(port, driver);
> > return tty_register_device_attr(driver, index, device, drvdata,
> > attr_grp);
> > }
> > @@ -183,6 +204,7 @@ struct device *tty_port_register_device_attr_serdev(struct tty_port *port,
> > struct device *dev;
> >
> > tty_port_link_device(port, driver, index);
> > + tty_port_link_driver_wq(port, driver);
> >
> > dev = serdev_tty_port_register(port, host, parent, driver, index);
> > if (PTR_ERR(dev) != -ENODEV) {
> > @@ -703,6 +725,7 @@ int tty_port_install(struct tty_port *port, struct tty_driver *driver,
> > struct tty_struct *tty)
> > {
> > tty->port = port;
> > + tty_port_link_driver_wq(port, driver);
> > return tty_standard_install(driver, tty);
> > }
> > EXPORT_SYMBOL_GPL(tty_port_install);
> > diff --git a/include/linux/tty_buffer.h b/include/linux/tty_buffer.h
> > index 31125e3be..48adcb0e8 100644
> > --- a/include/linux/tty_buffer.h
> > +++ b/include/linux/tty_buffer.h
> > @@ -34,6 +34,7 @@ static inline u8 *flag_buf_ptr(struct tty_buffer *b, unsigned int ofs)
> >
> > struct tty_bufhead {
> > struct tty_buffer *head; /* Queue head */
> > + struct workqueue_struct *flip_wq;
> > struct work_struct work;
> > struct mutex lock;
> > atomic_t priority;
> > diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
> > index 188ee9b76..9c65854f7 100644
> > --- a/include/linux/tty_driver.h
> > +++ b/include/linux/tty_driver.h
> > @@ -69,6 +69,10 @@ struct serial_struct;
> > * Do not create numbered ``/dev`` nodes. For example, create
> > * ``/dev/ttyprintk`` and not ``/dev/ttyprintk0``. Applicable only when a
> > * driver for a single tty device is being allocated.
> > + *
> > + * @TTY_DRIVER_CUSTOM_WORKQUEUE:
> > + * Do not create workqueue when tty_register_driver(). When set, flip
> > + * buffer workqueue shall be set by tty_port_link_wq() for every port.
> > */
> > enum tty_driver_flag {
> > TTY_DRIVER_INSTALLED = BIT(0),
> > @@ -79,6 +83,7 @@ enum tty_driver_flag {
> > TTY_DRIVER_HARDWARE_BREAK = BIT(5),
> > TTY_DRIVER_DYNAMIC_ALLOC = BIT(6),
> > TTY_DRIVER_UNNUMBERED_NODE = BIT(7),
> > + TTY_DRIVER_CUSTOM_WORKQUEUE = BIT(8),
> > };
> >
> > enum tty_driver_type {
> > @@ -506,6 +511,7 @@ struct tty_operations {
> > * @flags: tty driver flags (%TTY_DRIVER_)
> > * @proc_entry: proc fs entry, used internally
> > * @other: driver of the linked tty; only used for the PTY driver
> > + * @flip_wq: workqueue to queue flip buffer work on
> > * @ttys: array of active &struct tty_struct, set by tty_standard_install()
> > * @ports: array of &struct tty_port; can be set during initialization by
> > * tty_port_link_device() and similar
> > @@ -539,6 +545,7 @@ struct tty_driver {
> > unsigned long flags;
> > struct proc_dir_entry *proc_entry;
> > struct tty_driver *other;
> > + struct workqueue_struct *flip_wq;
> >
> > /*
> > * Pointer to the tty data structures
> > diff --git a/include/linux/tty_port.h b/include/linux/tty_port.h
> > index 660c254f1..c1b87f3c5 100644
> > --- a/include/linux/tty_port.h
> > +++ b/include/linux/tty_port.h
> > @@ -138,6 +138,7 @@ struct tty_port {
> > kernel */
> >
> > void tty_port_init(struct tty_port *port);
> > +void tty_port_link_wq(struct tty_port *port, struct workqueue_struct *flip_wq);
> > void tty_port_link_device(struct tty_port *port, struct tty_driver *driver,
> > unsigned index);
> > struct device *tty_port_register_device(struct tty_port *port,
> > @@ -165,6 +166,18 @@ static inline struct tty_port *tty_port_get(struct tty_port *port)
> > return NULL;
> > }
> >
> > +/*
> > + * Never overwrite the workqueue set by tty_port_link_wq().
> > + * No effect when %TTY_DRIVER_CUSTOM_WORKQUEUE is set, as driver->flip_wq is
> > + * %NULL.
> > + */
> > +static inline void tty_port_link_driver_wq(struct tty_port *port,
> > + struct tty_driver *driver)
> > +{
> > + if (!port->buf.flip_wq)
> > + port->buf.flip_wq = driver->flip_wq;
> > +}
> > +
> > /* If the cts flow control is enabled, return true. */
> > static inline bool tty_port_cts_enabled(const struct tty_port *port)
> > {
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
^ permalink raw reply
* Re: [PATCH v8] tty: tty_port: add workqueue to flip TTY buffer
From: Marek Szyprowski @ 2026-01-27 10:34 UTC (permalink / raw)
To: Xin Zhao, gregkh, jirislaby, tj; +Cc: hch, linux-kernel, linux-serial
In-Reply-To: <20251223034836.2625547-1-jackzxcui1989@163.com>
On 23.12.2025 04:48, Xin Zhao wrote:
> On the embedded platform, certain critical data, such as IMU data, is
> transmitted through UART. The tty_flip_buffer_push() interface in the TTY
> layer uses system_dfl_wq to handle the flipping of the TTY buffer.
> Although the unbound workqueue can create new threads on demand and wake
> up the kworker thread on an idle CPU, it may be preempted by real-time
> tasks or other high-prio tasks.
>
> flush_to_ldisc() needs to wake up the relevant data handle thread. When
> executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which
> does not disable preemption but disables migration in RT-Linux. This
> prevents the kworker thread from being migrated to other cores by CPU's
> balancing logic, resulting in long delays. The call trace is as follows:
> __wake_up_common_lock
> __wake_up
> ep_poll_callback
> __wake_up_common
> __wake_up_common_lock
> __wake_up
> n_tty_receive_buf_common
> n_tty_receive_buf2
> tty_ldisc_receive_buf
> tty_port_default_receive_buf
> flush_to_ldisc
>
> In our system, the processing interval for each frame of IMU data
> transmitted via UART can experience significant jitter due to this issue.
> Instead of the expected 10 to 15 ms frame processing interval, we see
> spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can
> be 2 to 3 occurrences of such high jitter, which is quite frequent. This
> jitter exceeds the software's tolerable limit of 20 ms.
>
> Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as
> default linked to default workqueue allocated when tty_register_driver().
> The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and
> nice can be set dynamically. The execution timing of tty_port_link_wq() is
> not clearly restricted. The newly added function tty_port_link_driver_wq()
> checks whether the flip_wq of the tty_port has already been assigned when
> linking the default tty_driver's workqueue to the port. After the user has
> set a custom workqueue for a certain tty_port using tty_port_link_wq(), the
> system will only use this custom workqueue, even if tty_driver does not
> have %TTY_DRIVER_CUSTOM_WORKQUEUE flag.
>
> Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the
> default single tty_driver workqueue. Two reasons why need to introduce the
> %TTY_DRIVER_CUSTOM_WORKQUEUE flag:
> 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will
> fail when trying to create a workqueue with the same name. The pty is an
> example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are
> enabled, the call to tty_register_driver() in unix98_pty_init() will fail.
> 2. Different tty ports may be used for different tasks, which may require
> separate core binding control via workqueues. In this case, the workqueue
> created by default in the tty driver is unnecessary. Enabling this flag
> prevents the creation of this redundant workqueue.
>
> After applying this patch, we can set the related UART TTY flip buffer
> workqueue by sysfs. We set the cpumask to CPU cores associated with the
> IMU tasks, and set the nice to -20. Testing has shown significant
> improvement in the previously described issue, with almost no stuttering
> occurring anymore.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
This patch landed in linux-next as commit d000422a46aa ("tty: tty_port:
add workqueue to flip TTY buffer"). In my tests I found that it causes
some regressions, see the comments in the code below.
> ---
>
> Change in v8:
> - Rebase code, use system_dfl_wq instead of system_unbound_wq.
>
> Change in v7:
> - Pty simply link to system_unbound_wq instead of allocating a custom one,
> as suggested by Jiri Slaby.
> - Modify some inappropriate expressions in the code comments,
> as suggested by Jiri Slaby.
> - Link to v7: https://lore.kernel.org/all/20251210125028.4174917-1-jackzxcui1989@163.com/T/#u
>
> Change in v6:
> - Modify many inappropriate expressions in the commit log and code comments,
> as suggested by Jiri Slaby.
> - Add reasons why need to introduce the %TTY_DRIVER_CUSTOM_WORKQUEUE in
> commit log.
> - Modify the error handling related to the allocation failure of workqueue in
> tty_register_driver(), as suggested by Jiri Slaby.
> - Add description of tty_port_link_driver_wq() in the commit log,
> as suggested by Jiri Slaby.
> - Link to v6: https://lore.kernel.org/all/20251210031827.3771327-1-jackzxcui1989@163.com/
>
> Change in v5:
> - Do not allocate workqueue twice when CONFIG_UNIX98_PTYS and
> CONFIG_LEGACY_PTYS are all enabled.
> - Link to v5: https://lore.kernel.org/all/20251205030829.1829987-1-jackzxcui1989@163.com/
>
> Change in v4:
> - Simplify the logic for creating and releasing the workqueue,
> as suggested by Tejun Heo.
> - Allocate single workqueue of one tty_driver as default, link it to
> port when tty_port register device or tty_driver.
> - Introduce tty_port_link_wq() to link specific workqueue to port.
> - Add driver flag %TTY_DRIVER_CUSTOM_WORKQUEUE meaning not to create the
> default single tty_driver workqueue.
> - Link to v4: https://lore.kernel.org/all/202512041303.7192024b-lkp@intel.com/T/#t
>
> Change in v3:
> - Add tty flip workqueue for all tty ports, as suggested by Greg KH.
> Every tty port use an individual flip workqueue, while all pty ports
> share the same workqueue created in pty_flip_wq_init().
> - Modify the commit log to describe the reason for latency spikes in
> RT-Linux.
> - Link to v3: https://lore.kernel.org/all/20251027060929.394053-1-jackzxcui1989@163.com/
>
> Change in v2:
> - Do not add new module parameters
> as suggested by Greg KH
> - Set WQ_SYSFS to allow properties changes from userspace
> as suggested by Tejun Heo
> - Link to v2: https://lore.kernel.org/all/20251024155534.2302590-1-jackzxcui1989@163.com
> ---
> drivers/tty/pty.c | 14 ++++++++++----
> drivers/tty/tty_buffer.c | 8 ++++----
> drivers/tty/tty_io.c | 21 ++++++++++++++++++++-
> drivers/tty/tty_port.c | 23 +++++++++++++++++++++++
> include/linux/tty_buffer.h | 1 +
> include/linux/tty_driver.h | 7 +++++++
> include/linux/tty_port.h | 13 +++++++++++++
> 7 files changed, 78 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index 6120d827a..1f17575f8 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -403,6 +403,8 @@ static int pty_common_install(struct tty_driver *driver, struct tty_struct *tty,
> o_tty->link = tty;
> tty_port_init(ports[0]);
> tty_port_init(ports[1]);
> + tty_port_link_wq(ports[0], system_dfl_wq);
> + tty_port_link_wq(ports[1], system_dfl_wq);
> tty_buffer_set_limit(ports[0], 8192);
> tty_buffer_set_limit(ports[1], 8192);
> o_tty->port = ports[0];
> @@ -532,14 +534,16 @@ static void __init legacy_pty_init(void)
> pty_driver = tty_alloc_driver(legacy_count,
> TTY_DRIVER_RESET_TERMIOS |
> TTY_DRIVER_REAL_RAW |
> - TTY_DRIVER_DYNAMIC_ALLOC);
> + TTY_DRIVER_DYNAMIC_ALLOC |
> + TTY_DRIVER_CUSTOM_WORKQUEUE);
> if (IS_ERR(pty_driver))
> panic("Couldn't allocate pty driver");
>
> pty_slave_driver = tty_alloc_driver(legacy_count,
> TTY_DRIVER_RESET_TERMIOS |
> TTY_DRIVER_REAL_RAW |
> - TTY_DRIVER_DYNAMIC_ALLOC);
> + TTY_DRIVER_DYNAMIC_ALLOC |
> + TTY_DRIVER_CUSTOM_WORKQUEUE);
> if (IS_ERR(pty_slave_driver))
> panic("Couldn't allocate pty slave driver");
>
> @@ -849,7 +853,8 @@ static void __init unix98_pty_init(void)
> TTY_DRIVER_REAL_RAW |
> TTY_DRIVER_DYNAMIC_DEV |
> TTY_DRIVER_DEVPTS_MEM |
> - TTY_DRIVER_DYNAMIC_ALLOC);
> + TTY_DRIVER_DYNAMIC_ALLOC |
> + TTY_DRIVER_CUSTOM_WORKQUEUE);
> if (IS_ERR(ptm_driver))
> panic("Couldn't allocate Unix98 ptm driver");
> pts_driver = tty_alloc_driver(NR_UNIX98_PTY_MAX,
> @@ -857,7 +862,8 @@ static void __init unix98_pty_init(void)
> TTY_DRIVER_REAL_RAW |
> TTY_DRIVER_DYNAMIC_DEV |
> TTY_DRIVER_DEVPTS_MEM |
> - TTY_DRIVER_DYNAMIC_ALLOC);
> + TTY_DRIVER_DYNAMIC_ALLOC |
> + TTY_DRIVER_CUSTOM_WORKQUEUE);
> if (IS_ERR(pts_driver))
> panic("Couldn't allocate Unix98 pts driver");
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 1a5673acd..86e1e7178 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -76,7 +76,7 @@ void tty_buffer_unlock_exclusive(struct tty_port *port)
> mutex_unlock(&buf->lock);
>
> if (restart)
> - queue_work(system_dfl_wq, &buf->work);
> + queue_work(buf->flip_wq, &buf->work);
> }
> EXPORT_SYMBOL_GPL(tty_buffer_unlock_exclusive);
>
> @@ -530,7 +530,7 @@ void tty_flip_buffer_push(struct tty_port *port)
> struct tty_bufhead *buf = &port->buf;
>
> tty_flip_buffer_commit(buf->tail);
> - queue_work(system_dfl_wq, &buf->work);
> + queue_work(buf->flip_wq, &buf->work);
> }
> EXPORT_SYMBOL(tty_flip_buffer_push);
>
> @@ -560,7 +560,7 @@ int tty_insert_flip_string_and_push_buffer(struct tty_port *port,
> tty_flip_buffer_commit(buf->tail);
> spin_unlock_irqrestore(&port->lock, flags);
>
> - queue_work(system_dfl_wq, &buf->work);
> + queue_work(buf->flip_wq, &buf->work);
>
> return size;
> }
> @@ -613,7 +613,7 @@ void tty_buffer_set_lock_subclass(struct tty_port *port)
>
> bool tty_buffer_restart_work(struct tty_port *port)
> {
> - return queue_work(system_dfl_wq, &port->buf.work);
> + return queue_work(port->buf.flip_wq, &port->buf.work);
> }
>
> bool tty_buffer_cancel_work(struct tty_port *port)
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e2d92cf70..d64fb08ba 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3446,10 +3446,23 @@ int tty_register_driver(struct tty_driver *driver)
> if (error < 0)
> goto err;
>
> + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE)) {
> + driver->flip_wq = alloc_workqueue("%s-flip-wq", WQ_UNBOUND | WQ_SYSFS,
> + 0, driver->name);
It looks that driver->name is not unique on some systems, see:
$ git grep ttyMSM drivers/tty/
drivers/tty/serial/msm_serial.c: .name = "ttyMSM",
drivers/tty/serial/msm_serial.c: .dev_name = "ttyMSM",
drivers/tty/serial/qcom_geni_serial.c: .name = "ttyMSM",
drivers/tty/serial/qcom_geni_serial.c: .dev_name = "ttyMSM",
This fails on Qualcomm RB5 boards, breaking the boot process (booting
hangs, because drivers try to use the unregistered wq):
sysfs: cannot create duplicate filename
'/devices/virtual/workqueue/ttyMSM-flip-wq'
CPU: 6 UID: 0 PID: 1 Comm: swapper/0 Not tainted
6.19.0-rc7-next-20260126+ #16440 PREEMPT
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0xc0/0xd0
dump_stack+0x18/0x24
sysfs_warn_dup+0x64/0x80
sysfs_create_dir_ns+0xe8/0x108
kobject_add_internal+0x98/0x270
kobject_add+0x94/0x10c
device_add+0xec/0x720
device_register+0x20/0x30
workqueue_sysfs_register+0x8c/0x170
__alloc_workqueue+0x554/0x668
alloc_workqueue_noprof+0x5c/0xfc
tty_register_driver+0x120/0x2d0
uart_register_driver+0x120/0x1b0
qcom_geni_serial_init+0x20/0xc8
do_one_initcall+0x64/0x308
kernel_init_freeable+0x284/0x508
kernel_init+0x24/0x1dc
ret_from_fork+0x10/0x20
kobject: kobject_add_internal failed for ttyMSM-flip-wq with -EEXIST,
don't try to register things with the same name in the same directory.
Changing the above alloc_workqueue() to use 'driver->driver_name' fixes
the boot issue. If keeping the driver->name is desired, then maybe the
'"%s-%s-flip-wq", ..., driver->name, driver->driver_name' format is a
better one.
The other issue with this patch I've observed on ARM Juno R1 board. With
one of the above fixes for the workqueue name, the boot process is still
broken because of the NULL pointer dereference:
input: gpio-keys as /de ** replaying previous printk message ** input:
gpio-keys as /devices/platform/gpio-keys/input/input3 Unable to handle
kernel NULL pointer dereference at virtual address 00000000000001c0 Mem
abort info: ... [00000000000001c0] user address but active_mm is swapper
Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU:
1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-rc7-next-20260126+
#16443 PREEMPT Hardware name: ARM Juno development board (r1) (DT)
pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
__queue_work+0x30/0x7c4 lr : queue_work_on+0xac/0xdc ... Call trace:
__queue_work+0x30/0x7c4 (P) queue_work_on+0xac/0xdc
tty_flip_buffer_push+0x2c/0x38 k_fn.part.0+0x7c/0xc8 k_fn+0x20/0x2c
kbd_event+0x2d8/0x504 input_handle_events_default+0x50/0x74
input_pass_values+0x148/0x2b4 input_handle_event+0xcc/0x5e0
input_event+0x64/0xa4 gpio_keys_open+0x9c/0xc4
input_open_device+0x8c/0x128 kbd_connect+0x84/0xa0
input_attach_handler+0x9c/0xf4 input_register_device+0x308/0x48c
gpio_keys_probe+0x40c/0xafc platform_probe+0x5c/0xac
really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c
driver_probe_device+0xdc/0x164 __driver_attach+0xe4/0x224
bus_for_each_dev+0x74/0xd0 driver_attach+0x24/0x30
bus_add_driver+0xe4/0x208 driver_register+0x60/0x128
__platform_driver_register+0x24/0x30 gpio_keys_init+0x1c/0x28
do_one_initcall+0x64/0x308 kernel_init_freeable+0x284/0x508
kernel_init+0x24/0x1dc ret_from_fork+0x10/0x20 Code: a9025bf5 a90573fb
aa0203fb 35001843 (b941c260) ---[ end trace 0000000000000000 ]--- note:
swapper/0[1] exited with irqs disabled note: swapper/0[1] exited with
preempt_count 3 Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b SMP: stopping secondary CPUs Kernel Offset: disabled
CPU features: 0x1040000,41858004,00020000,0400421b Memory Limit: none
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
Reverting $subject on top of current linux-next fixes this issue.
> + if (!driver->flip_wq) {
> + error = -ENOMEM;
> + goto err_unreg_char;
> + }
> + for (i = 0; i < driver->num; i++) {
> + if (driver->ports[i])
> + tty_port_link_driver_wq(driver->ports[i], driver);
> + }
> + }
> +
> if (driver->flags & TTY_DRIVER_DYNAMIC_ALLOC) {
> error = tty_cdev_add(driver, dev, 0, driver->num);
> if (error)
> - goto err_unreg_char;
> + goto err_destroy_wq;
> }
>
> scoped_guard(mutex, &tty_mutex)
> @@ -3475,6 +3488,10 @@ int tty_register_driver(struct tty_driver *driver)
> scoped_guard(mutex, &tty_mutex)
> list_del(&driver->tty_drivers);
>
> +err_destroy_wq:
> + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE))
> + destroy_workqueue(driver->flip_wq);
> +
> err_unreg_char:
> unregister_chrdev_region(dev, driver->num);
> err:
> @@ -3494,6 +3511,8 @@ void tty_unregister_driver(struct tty_driver *driver)
> driver->num);
> scoped_guard(mutex, &tty_mutex)
> list_del(&driver->tty_drivers);
> + if (!(driver->flags & TTY_DRIVER_CUSTOM_WORKQUEUE))
> + destroy_workqueue(driver->flip_wq);
> }
> EXPORT_SYMBOL(tty_unregister_driver);
>
> diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
> index fe67c5cb0..611f87814 100644
> --- a/drivers/tty/tty_port.c
> +++ b/drivers/tty/tty_port.c
> @@ -99,6 +99,26 @@ void tty_port_init(struct tty_port *port)
> }
> EXPORT_SYMBOL(tty_port_init);
>
> +/**
> + * tty_port_link_wq - link tty_port and flip workqueue
> + * @port: tty_port of the device
> + * @flip_wq: workqueue to queue flip buffer work on
> + *
> + * When %TTY_DRIVER_CUSTOM_WORKQUEUE is used, every tty_port shall be linked to
> + * a workqueue manually by this function, otherwise tty_flip_buffer_push() will
> + * see %NULL flip_wq pointer on queue_work.
> + * When %TTY_DRIVER_CUSTOM_WORKQUEUE is NOT used, the function can be used to
> + * link a certain port to a specific workqueue, instead of using the workqueue
> + * allocated in tty_register_driver().
> + *
> + * Note that TTY port API will NOT destroy the workqueue.
> + */
> +void tty_port_link_wq(struct tty_port *port, struct workqueue_struct *flip_wq)
> +{
> + port->buf.flip_wq = flip_wq;
> +}
> +EXPORT_SYMBOL_GPL(tty_port_link_wq);
> +
> /**
> * tty_port_link_device - link tty and tty_port
> * @port: tty_port of the device
> @@ -157,6 +177,7 @@ struct device *tty_port_register_device_attr(struct tty_port *port,
> const struct attribute_group **attr_grp)
> {
> tty_port_link_device(port, driver, index);
> + tty_port_link_driver_wq(port, driver);
> return tty_register_device_attr(driver, index, device, drvdata,
> attr_grp);
> }
> @@ -183,6 +204,7 @@ struct device *tty_port_register_device_attr_serdev(struct tty_port *port,
> struct device *dev;
>
> tty_port_link_device(port, driver, index);
> + tty_port_link_driver_wq(port, driver);
>
> dev = serdev_tty_port_register(port, host, parent, driver, index);
> if (PTR_ERR(dev) != -ENODEV) {
> @@ -703,6 +725,7 @@ int tty_port_install(struct tty_port *port, struct tty_driver *driver,
> struct tty_struct *tty)
> {
> tty->port = port;
> + tty_port_link_driver_wq(port, driver);
> return tty_standard_install(driver, tty);
> }
> EXPORT_SYMBOL_GPL(tty_port_install);
> diff --git a/include/linux/tty_buffer.h b/include/linux/tty_buffer.h
> index 31125e3be..48adcb0e8 100644
> --- a/include/linux/tty_buffer.h
> +++ b/include/linux/tty_buffer.h
> @@ -34,6 +34,7 @@ static inline u8 *flag_buf_ptr(struct tty_buffer *b, unsigned int ofs)
>
> struct tty_bufhead {
> struct tty_buffer *head; /* Queue head */
> + struct workqueue_struct *flip_wq;
> struct work_struct work;
> struct mutex lock;
> atomic_t priority;
> diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
> index 188ee9b76..9c65854f7 100644
> --- a/include/linux/tty_driver.h
> +++ b/include/linux/tty_driver.h
> @@ -69,6 +69,10 @@ struct serial_struct;
> * Do not create numbered ``/dev`` nodes. For example, create
> * ``/dev/ttyprintk`` and not ``/dev/ttyprintk0``. Applicable only when a
> * driver for a single tty device is being allocated.
> + *
> + * @TTY_DRIVER_CUSTOM_WORKQUEUE:
> + * Do not create workqueue when tty_register_driver(). When set, flip
> + * buffer workqueue shall be set by tty_port_link_wq() for every port.
> */
> enum tty_driver_flag {
> TTY_DRIVER_INSTALLED = BIT(0),
> @@ -79,6 +83,7 @@ enum tty_driver_flag {
> TTY_DRIVER_HARDWARE_BREAK = BIT(5),
> TTY_DRIVER_DYNAMIC_ALLOC = BIT(6),
> TTY_DRIVER_UNNUMBERED_NODE = BIT(7),
> + TTY_DRIVER_CUSTOM_WORKQUEUE = BIT(8),
> };
>
> enum tty_driver_type {
> @@ -506,6 +511,7 @@ struct tty_operations {
> * @flags: tty driver flags (%TTY_DRIVER_)
> * @proc_entry: proc fs entry, used internally
> * @other: driver of the linked tty; only used for the PTY driver
> + * @flip_wq: workqueue to queue flip buffer work on
> * @ttys: array of active &struct tty_struct, set by tty_standard_install()
> * @ports: array of &struct tty_port; can be set during initialization by
> * tty_port_link_device() and similar
> @@ -539,6 +545,7 @@ struct tty_driver {
> unsigned long flags;
> struct proc_dir_entry *proc_entry;
> struct tty_driver *other;
> + struct workqueue_struct *flip_wq;
>
> /*
> * Pointer to the tty data structures
> diff --git a/include/linux/tty_port.h b/include/linux/tty_port.h
> index 660c254f1..c1b87f3c5 100644
> --- a/include/linux/tty_port.h
> +++ b/include/linux/tty_port.h
> @@ -138,6 +138,7 @@ struct tty_port {
> kernel */
>
> void tty_port_init(struct tty_port *port);
> +void tty_port_link_wq(struct tty_port *port, struct workqueue_struct *flip_wq);
> void tty_port_link_device(struct tty_port *port, struct tty_driver *driver,
> unsigned index);
> struct device *tty_port_register_device(struct tty_port *port,
> @@ -165,6 +166,18 @@ static inline struct tty_port *tty_port_get(struct tty_port *port)
> return NULL;
> }
>
> +/*
> + * Never overwrite the workqueue set by tty_port_link_wq().
> + * No effect when %TTY_DRIVER_CUSTOM_WORKQUEUE is set, as driver->flip_wq is
> + * %NULL.
> + */
> +static inline void tty_port_link_driver_wq(struct tty_port *port,
> + struct tty_driver *driver)
> +{
> + if (!port->buf.flip_wq)
> + port->buf.flip_wq = driver->flip_wq;
> +}
> +
> /* If the cts flow control is enabled, return true. */
> static inline bool tty_port_cts_enabled(const struct tty_port *port)
> {
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v5 06/11] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: Linus Walleij @ 2026-01-27 9:32 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov, Conor Dooley
In-Reply-To: <20260115114021.111324-7-robert.marko@sartura.hr>
On Thu, Jan 15, 2026 at 12:41 PM Robert Marko <robert.marko@sartura.hr> wrote:
> Document LAN969x compatibles for SGPIO.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
This patch 6/11 applied to the pinctrl tree!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 23:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012620-retool-gloater-6cd3@gregkh>
On 26/01/2026 15:36, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>>>>>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>>>>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>>>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>>>>>> on the kernel command line to enable it or not.
>>>>>>>>>
>>>>>>>>> This says what is happening, but not why?
>>>>>>>>>
>>>>>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>>>>>
>>>>>>>>> Why are we using a 1990's technology for a new feature? What is this
>>>>>>>>> going to allow to have happen? Who needs/wants this? Who will use it?
>>>>>>>>> For what?
>>>>>>>>
>>>>>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>>>>>
>>>>>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>>>>>> without rebuilding the kernel.
>>>>>>>
>>>>>>> But that's a distro-specific thing, the distro should be enabling or
>>>>>>> disabling the option as it needs, it should not be a user-configurable
>>>>>>> boot-time selection option as userspace depends entirely on this either
>>>>>>> being there or not. Why would you have a kernel with both options but
>>>>>>> userspace without that?
>>>>>>
>>>>>> Actually the userspace side works with or without VT, at least with Fedora,
>>>>>> I've my Gnome session in both cases.
>>>>>
>>>>> Great! Then why is this even needed? Who wants such a "let's not make
>>>>> up our mind until we boot" type of system?
>>>>>
>>>>> Given that traditionally the command line is a "secure" thing, that is
>>>>> locked down by distros and orginizations, who would ever be able to be
>>>>> changing this type of thing? Who would want to support userspace that
>>>>> handles both at the same time?
>>>>>
>>>>> I don't see the issue here, if a distro doesn't want to support VT, then
>>>>> disable it in the kernel and all is good. If they do want to support
>>>>> it, than enable it. Don't do both :)
>>>>
>>>> Maybe the real issue is that VT cannot be built as a module.
>>>> That way the userspace would be able to load it only if it needs it.
>>>>
>>>> That's probably more complex than my 3 lines patch, but I can try.
>>>> Would you prefer it that way?
>>>
>>> If that would make it simpler for a distro to handle this, perhaps. Try
>>> it and see, I think the last time this came up, unwinding this into a
>>> module just wasn't possible, but that might have been a long time ago, I
>>> can't recall.
>>>
>>> But again, why wouldn't a distro pick a "this is what we are going to
>>> support" line and stick with it? Why would they want to support both?
>>>
>>
>> It's all about the transition. Talks about VT-less system started in 2012,
>> but since then no major desktop Linux distribution have done it.
>
> Then perhaps it's not really ever going to happen if no one actually
> does the work and wants their distro to change to not have it.
To give some contexts, I proposed to switch to kmscon for Fedora 44, so
once we are there, it will be feasible to switch off VT, in 1 or 2
years. But the requirement to rebuild the kernel, makes it painful to
test, and much harder to get accepted.
>> I think that one of the reason, is that if you switch off VT, of course some
>> users will complain, as it has a lot of implications.
>
> Again, that's a distro's policy decision to make, don't force the kernel
> to support a wishy-washy distro's decision :)
Agreed, I can also keep this patch as downstream, if you think it's
better that way. But I though it may interest other distributions as well.
>
>> Telling them to go rebuild their kernel is not good.
>
> Agreed, this is a policy decision a distro needs to make.
>
>> Telling them to run
>> grubby to change the kernel command line until they find alternative for
>> their use case is better. They can experiment and do the switch when they
>> are ready.
>> Really it's nothing more than that.
>
> Again, policy decision that a distro needs to make.
>
>> I don't think a distribution will want to maintain VT and noVT for a long
>> time.
>
> Please define "long time" given that no distro has even done this yet?
I hope it won't get longer than 1 or 2 year.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 22:59 UTC (permalink / raw)
To: Nicolas Pitre, Greg Kroah-Hartman
Cc: Jiri Slaby, Calixte Pernot, linux-kernel, linux-serial
In-Reply-To: <28snspp2-3912-rs5o-04s0-1648504sq90r@syhkavp.arg>
On 26/01/2026 18:24, Nicolas Pitre wrote:
> On Mon, 26 Jan 2026, Greg Kroah-Hartman wrote:
>
>> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
>>> I think that one of the reason, is that if you switch off VT, of course some
>>> users will complain, as it has a lot of implications.
>>
>> Again, that's a distro's policy decision to make, don't force the kernel
>> to support a wishy-washy distro's decision :)
>
> As a daily VT user for my primary Linux interface due to accessibility
> needs, I'm baffled by the idea of distributions removing this support.
>
> Of course this has lots of implications. For many users with
> disabilities, VT is not optional - it's the only _fully_ usable
> interface.
>
> Consider this my official objection. Just don't do that.
That patch is clearly for people like you, that will need more time to
adapt their tools and workflow to a VT-less system.
It's also less practical to develop alternative, if you need to rebuild
your kernel to disable VT.
Regarding accessibility, I don't see any technical reason why a VT-less
system would be less efficient that what is currently available with VT.
--
Jocelyn
>
>
> Nicolas
>
^ permalink raw reply
* [PATCH] printk, vt, fbcon: Remove console_conditional_schedule()
From: Sebastian Andrzej Siewior @ 2026-01-26 18:08 UTC (permalink / raw)
To: linux-kernel, linux-serial, linux-fbdev, dri-devel,
linux-rt-devel
Cc: Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Greg Kroah-Hartman, Jiri Slaby, Simona Vetter, Helge Deller
do_con_write(), fbcon_redraw.*() invoke console_conditional_schedule()
which is a conditional scheduling point based on printk's internal
variables console_may_schedule. It may only be used if the console lock
is acquired for instance via console_lock() or console_trylock().
Prinkt sets the internal variable to 1 (and allows to schedule)
if the console lock has been acquired via console_lock(). The trylock
does not allow it.
The console_conditional_schedule() invocation in do_con_write() is
invoked shortly before console_unlock().
The console_conditional_schedule() invocation in fbcon_redraw.*()
original from fbcon_scroll() / vt's con_scroll() which originate from a
line feed.
In console_unlock() the variable is set to 0 (forbids to schedule) and
it tries to schedule while making progress printing. This is brand new
compared to when console_conditional_schedule() was added in v2.4.9.11.
In v2.6.38-rc3, console_unlock() (started its existence) iterated over
all consoles and flushed them with disabled interrupts. A scheduling
attempt here was not possible, it relied that a long print scheduled
before console_unlock().
Since commit 8d91f8b15361d ("printk: do cond_resched() between lines
while outputting to consoles"), which appeared in v4.5-rc1,
console_unlock() attempts to schedule if it was allowed to schedule
while during console_lock(). Each record is idealy one line so after
every line feed.
This console_conditional_schedule() is also only relevant on
PREEMPT_NONE and PREEMPT_VOLUNTARY builds. In other configurations
cond_resched() becomes a nop and has no impact.
I'm bringing this all up just proof that it is not required anymore. It
becomes a problem on a PREEMPT_RT build with debug code enabled because
that might_sleep() in cond_resched() remains and triggers a warnings.
This is due to
legacy_kthread_func-> console_flush_one_record -> vt_console_print-> lf
-> con_scroll -> fbcon_scroll
and vt_console_print() acquires a spinlock_t which does not allow a
voluntary schedule. There is no need to fb_scroll() to schedule since
console_flush_one_record() attempts to schedule after each line.
!PREEMPT_RT is not affected because the legacy printing thread is only
enabled on PREEMPT_RT builds.
Therefore I suggest to remove console_conditional_schedule().
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Fixes: 5f53ca3ff83b4 ("printk: Implement legacy printer kthread for PREEMPT_RT")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
A follow-up to
https://lore.kernel.org/all/20260114145955.d924Z-zu@linutronix.de/
drivers/tty/vt/vt.c | 1 -
drivers/video/fbdev/core/fbcon.c | 6 ------
include/linux/console.h | 1 -
kernel/printk/printk.c | 16 ----------------
4 files changed, 24 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..53daf7614b1af 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3236,7 +3236,6 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
goto rescan_last_byte;
}
con_flush(vc, &draw);
- console_conditional_schedule();
notify_update(vc);
return n;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7be9e865325d9..36dd9d4a46ae0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1607,12 +1607,10 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
start = s;
}
}
- console_conditional_schedule();
s++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, dy, x);
- console_conditional_schedule();
dy++;
}
}
@@ -1648,14 +1646,12 @@ static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
par->bitops->bmove(vc, info, line + ycount, x, line, x, 1,
s - start);
- console_conditional_schedule();
if (ycount > 0)
line++;
else {
@@ -1703,13 +1699,11 @@ static void fbcon_redraw(struct vc_data *vc, int line, int count, int offset)
}
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, line, x);
- console_conditional_schedule();
if (offset > 0)
line++;
else {
diff --git a/include/linux/console.h b/include/linux/console.h
index fc9f5c5c1b04c..ec506d3501965 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -697,7 +697,6 @@ extern int unregister_console(struct console *);
extern void console_lock(void);
extern int console_trylock(void);
extern void console_unlock(void);
-extern void console_conditional_schedule(void);
extern void console_unblank(void);
extern void console_flush_on_panic(enum con_flush_mode mode);
extern struct tty_driver *console_device(int *);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1d765ad242b82..9296bf41aa49d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3362,22 +3362,6 @@ void console_unlock(void)
}
EXPORT_SYMBOL(console_unlock);
-/**
- * console_conditional_schedule - yield the CPU if required
- *
- * If the console code is currently allowed to sleep, and
- * if this CPU should yield the CPU to another task, do
- * so here.
- *
- * Must be called within console_lock();.
- */
-void __sched console_conditional_schedule(void)
-{
- if (console_may_schedule)
- cond_resched();
-}
-EXPORT_SYMBOL(console_conditional_schedule);
-
void console_unblank(void)
{
bool found_unblank = false;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] vt: Add enable module parameter
From: Nicolas Pitre @ 2026-01-26 17:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jocelyn Falempe, Jiri Slaby, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012620-retool-gloater-6cd3@gregkh>
On Mon, 26 Jan 2026, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
> > I think that one of the reason, is that if you switch off VT, of course some
> > users will complain, as it has a lot of implications.
>
> Again, that's a distro's policy decision to make, don't force the kernel
> to support a wishy-washy distro's decision :)
As a daily VT user for my primary Linux interface due to accessibility
needs, I'm baffled by the idea of distributions removing this support.
Of course this has lots of implications. For many users with
disabilities, VT is not optional - it's the only _fully_ usable
interface.
Consider this my official objection. Just don't do that.
Nicolas
^ permalink raw reply
* Re: [PATCH 6/6] serial: 8250_dw: Ensure BUSY is deasserted
From: Greg Kroah-Hartman @ 2026-01-26 15:22 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jiri Slaby, linux-serial, Andy Shevchenko, qianfan Zhao,
Adriana Nicolae, Markus Mayer, Tim Kryger, Matt Porter,
Heikki Krogerus, Jamie Iles, linux-kernel, stable,
Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-7-ilpo.jarvinen@linux.intel.com>
On Fri, Jan 23, 2026 at 07:27:39PM +0200, Ilpo Järvinen wrote:
> DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
> Existance of BUSY depends on uart_16550_compatible, if UART HW is
> configured with 16550 compatible those registers can always be written.
>
> There currently is dw8250_force_idle() which attempts to archive
> non-BUSY state by disabling FIFO, however, the solution is unreliable
> when Rx keeps getting more and more characters.
>
> Create a sequence of operations to enforce that ensures UART cannot
> keep BUSY asserted indefinitely. The new sequence relies on enabling
> loopback mode temporarily to prevent incoming Rx characters keeping
> UART BUSY.
>
> Ensure no Tx in ongoing while the UART is switches into the loopback
> mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding
> DMA Tx pause/resume functions).
>
> According to tests performed by Adriana Nicolae <adriana@arista.com>,
> simply disabling FIFO or clearing FIFOs only once does not always
> ensure BUSY is deasserted but up to two tries may be needed. This could
> be related to ongoing Rx of a character (a guess, not known for sure).
> Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary
> number but using, e.g., p->fifosize seems overly large). Tests
> performed by others did not exhibit similar challenge but it does not
> seem harmful to leave the FIFO clearing loop in place for all DW UARTs
> with BUSY functionality.
>
> Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
> writes. In case of plain LCR writes, opportunistically try to update
> LCR first and only invoke dw8250_idle_enter() if the write did not
> succeed (it has been observed that in practice most LCR writes do
> succeed without complications).
>
> This issue was first reported by qianfan Zhao who put lots of debugging
> effort into understanding the solution space.
>
> Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround")
> Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver")
> Cc: <stable@vger.kernel.org>
Why is patch 6/6 only marked for stable? If this is needed "now",
shouldn't this be a separate patch? Do you need all of the first 5 for
this to work properly?
I can't take this series as-is because I don't know how to route it :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 14:36 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <286bfe2e-796e-4c71-a75c-4967450edaab@redhat.com>
On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> > > > > On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > > > > on the kernel command line to enable it or not.
> > > > > > > >
> > > > > > > > This says what is happening, but not why?
> > > > > > > >
> > > > > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > > > > >
> > > > > > > > Why are we using a 1990's technology for a new feature? What is this
> > > > > > > > going to allow to have happen? Who needs/wants this? Who will use it?
> > > > > > > > For what?
> > > > > > >
> > > > > > > The goal is to ease the transition to disable CONFIG_VT.
> > > > > > >
> > > > > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > > > > without rebuilding the kernel.
> > > > > >
> > > > > > But that's a distro-specific thing, the distro should be enabling or
> > > > > > disabling the option as it needs, it should not be a user-configurable
> > > > > > boot-time selection option as userspace depends entirely on this either
> > > > > > being there or not. Why would you have a kernel with both options but
> > > > > > userspace without that?
> > > > >
> > > > > Actually the userspace side works with or without VT, at least with Fedora,
> > > > > I've my Gnome session in both cases.
> > > >
> > > > Great! Then why is this even needed? Who wants such a "let's not make
> > > > up our mind until we boot" type of system?
> > > >
> > > > Given that traditionally the command line is a "secure" thing, that is
> > > > locked down by distros and orginizations, who would ever be able to be
> > > > changing this type of thing? Who would want to support userspace that
> > > > handles both at the same time?
> > > >
> > > > I don't see the issue here, if a distro doesn't want to support VT, then
> > > > disable it in the kernel and all is good. If they do want to support
> > > > it, than enable it. Don't do both :)
> > >
> > > Maybe the real issue is that VT cannot be built as a module.
> > > That way the userspace would be able to load it only if it needs it.
> > >
> > > That's probably more complex than my 3 lines patch, but I can try.
> > > Would you prefer it that way?
> >
> > If that would make it simpler for a distro to handle this, perhaps. Try
> > it and see, I think the last time this came up, unwinding this into a
> > module just wasn't possible, but that might have been a long time ago, I
> > can't recall.
> >
> > But again, why wouldn't a distro pick a "this is what we are going to
> > support" line and stick with it? Why would they want to support both?
> >
>
> It's all about the transition. Talks about VT-less system started in 2012,
> but since then no major desktop Linux distribution have done it.
Then perhaps it's not really ever going to happen if no one actually
does the work and wants their distro to change to not have it.
> I think that one of the reason, is that if you switch off VT, of course some
> users will complain, as it has a lot of implications.
Again, that's a distro's policy decision to make, don't force the kernel
to support a wishy-washy distro's decision :)
> Telling them to go rebuild their kernel is not good.
Agreed, this is a policy decision a distro needs to make.
> Telling them to run
> grubby to change the kernel command line until they find alternative for
> their use case is better. They can experiment and do the switch when they
> are ready.
> Really it's nothing more than that.
Again, policy decision that a distro needs to make.
> I don't think a distribution will want to maintain VT and noVT for a long
> time.
Please define "long time" given that no distro has even done this yet?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 13:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012653-designer-capably-d575@gregkh>
On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>>>> on the kernel command line to enable it or not.
>>>>>>>
>>>>>>> This says what is happening, but not why?
>>>>>>>
>>>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>>>
>>>>>>> Why are we using a 1990's technology for a new feature? What is this
>>>>>>> going to allow to have happen? Who needs/wants this? Who will use it?
>>>>>>> For what?
>>>>>>
>>>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>>>
>>>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>>>> without rebuilding the kernel.
>>>>>
>>>>> But that's a distro-specific thing, the distro should be enabling or
>>>>> disabling the option as it needs, it should not be a user-configurable
>>>>> boot-time selection option as userspace depends entirely on this either
>>>>> being there or not. Why would you have a kernel with both options but
>>>>> userspace without that?
>>>>
>>>> Actually the userspace side works with or without VT, at least with Fedora,
>>>> I've my Gnome session in both cases.
>>>
>>> Great! Then why is this even needed? Who wants such a "let's not make
>>> up our mind until we boot" type of system?
>>>
>>> Given that traditionally the command line is a "secure" thing, that is
>>> locked down by distros and orginizations, who would ever be able to be
>>> changing this type of thing? Who would want to support userspace that
>>> handles both at the same time?
>>>
>>> I don't see the issue here, if a distro doesn't want to support VT, then
>>> disable it in the kernel and all is good. If they do want to support
>>> it, than enable it. Don't do both :)
>>
>> Maybe the real issue is that VT cannot be built as a module.
>> That way the userspace would be able to load it only if it needs it.
>>
>> That's probably more complex than my 3 lines patch, but I can try.
>> Would you prefer it that way?
>
> If that would make it simpler for a distro to handle this, perhaps. Try
> it and see, I think the last time this came up, unwinding this into a
> module just wasn't possible, but that might have been a long time ago, I
> can't recall.
>
> But again, why wouldn't a distro pick a "this is what we are going to
> support" line and stick with it? Why would they want to support both?
>
It's all about the transition. Talks about VT-less system started in
2012, but since then no major desktop Linux distribution have done it.
I think that one of the reason, is that if you switch off VT, of course
some users will complain, as it has a lot of implications.
Telling them to go rebuild their kernel is not good. Telling them to run
grubby to change the kernel command line until they find alternative for
their use case is better. They can experiment and do the switch when
they are ready.
Really it's nothing more than that.
I don't think a distribution will want to maintain VT and noVT for a
long time.
Thanks,
--
Jocelyn
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 12:46 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com>
On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > > on the kernel command line to enable it or not.
> > > > > >
> > > > > > This says what is happening, but not why?
> > > > > >
> > > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > > >
> > > > > > Why are we using a 1990's technology for a new feature? What is this
> > > > > > going to allow to have happen? Who needs/wants this? Who will use it?
> > > > > > For what?
> > > > >
> > > > > The goal is to ease the transition to disable CONFIG_VT.
> > > > >
> > > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > > without rebuilding the kernel.
> > > >
> > > > But that's a distro-specific thing, the distro should be enabling or
> > > > disabling the option as it needs, it should not be a user-configurable
> > > > boot-time selection option as userspace depends entirely on this either
> > > > being there or not. Why would you have a kernel with both options but
> > > > userspace without that?
> > >
> > > Actually the userspace side works with or without VT, at least with Fedora,
> > > I've my Gnome session in both cases.
> >
> > Great! Then why is this even needed? Who wants such a "let's not make
> > up our mind until we boot" type of system?
> >
> > Given that traditionally the command line is a "secure" thing, that is
> > locked down by distros and orginizations, who would ever be able to be
> > changing this type of thing? Who would want to support userspace that
> > handles both at the same time?
> >
> > I don't see the issue here, if a distro doesn't want to support VT, then
> > disable it in the kernel and all is good. If they do want to support
> > it, than enable it. Don't do both :)
>
> Maybe the real issue is that VT cannot be built as a module.
> That way the userspace would be able to load it only if it needs it.
>
> That's probably more complex than my 3 lines patch, but I can try.
> Would you prefer it that way?
If that would make it simpler for a distro to handle this, perhaps. Try
it and see, I think the last time this came up, unwinding this into a
module just wasn't possible, but that might have been a long time ago, I
can't recall.
But again, why wouldn't a distro pick a "this is what we are going to
support" line and stick with it? Why would they want to support both?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 12:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012642-threefold-atypical-a3ad@gregkh>
On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>> on the kernel command line to enable it or not.
>>>>>
>>>>> This says what is happening, but not why?
>>>>>
>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>
>>>>> Why are we using a 1990's technology for a new feature? What is this
>>>>> going to allow to have happen? Who needs/wants this? Who will use it?
>>>>> For what?
>>>>
>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>
>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>> without rebuilding the kernel.
>>>
>>> But that's a distro-specific thing, the distro should be enabling or
>>> disabling the option as it needs, it should not be a user-configurable
>>> boot-time selection option as userspace depends entirely on this either
>>> being there or not. Why would you have a kernel with both options but
>>> userspace without that?
>>
>> Actually the userspace side works with or without VT, at least with Fedora,
>> I've my Gnome session in both cases.
>
> Great! Then why is this even needed? Who wants such a "let's not make
> up our mind until we boot" type of system?
>
> Given that traditionally the command line is a "secure" thing, that is
> locked down by distros and orginizations, who would ever be able to be
> changing this type of thing? Who would want to support userspace that
> handles both at the same time?
>
> I don't see the issue here, if a distro doesn't want to support VT, then
> disable it in the kernel and all is good. If they do want to support
> it, than enable it. Don't do both :)
Maybe the real issue is that VT cannot be built as a module.
That way the userspace would be able to load it only if it needs it.
That's probably more complex than my 3 lines patch, but I can try.
Would you prefer it that way?
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 10:59 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <45526d98-57b6-456e-babc-61b7331318c0@redhat.com>
On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > on the kernel command line to enable it or not.
> > > >
> > > > This says what is happening, but not why?
> > > >
> > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > >
> > > > Why are we using a 1990's technology for a new feature? What is this
> > > > going to allow to have happen? Who needs/wants this? Who will use it?
> > > > For what?
> > >
> > > The goal is to ease the transition to disable CONFIG_VT.
> > >
> > > So if this is merged, you can boot without VT on any Linux distribution,
> > > without rebuilding the kernel.
> >
> > But that's a distro-specific thing, the distro should be enabling or
> > disabling the option as it needs, it should not be a user-configurable
> > boot-time selection option as userspace depends entirely on this either
> > being there or not. Why would you have a kernel with both options but
> > userspace without that?
>
> Actually the userspace side works with or without VT, at least with Fedora,
> I've my Gnome session in both cases.
Great! Then why is this even needed? Who wants such a "let's not make
up our mind until we boot" type of system?
Given that traditionally the command line is a "secure" thing, that is
locked down by distros and orginizations, who would ever be able to be
changing this type of thing? Who would want to support userspace that
handles both at the same time?
I don't see the issue here, if a distro doesn't want to support VT, then
disable it in the kernel and all is good. If they do want to support
it, than enable it. Don't do both :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 10:57 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <40fa8cab-af36-4420-9099-511474833fe1@redhat.com>
On Mon, Jan 26, 2026 at 11:49:45AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:30, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > on the kernel command line to enable it or not.
> > > > >
> > > > > This says what is happening, but not why?
> > > > >
> > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > >
> > > > > Why are we using a 1990's technology for a new feature? What is this
> > > > > going to allow to have happen? Who needs/wants this? Who will use it?
> > > > > For what?
> > > >
> > > > The goal is to ease the transition to disable CONFIG_VT.
> > > >
> > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > without rebuilding the kernel.
> > >
> > > But that's a distro-specific thing, the distro should be enabling or
> > > disabling the option as it needs, it should not be a user-configurable
> > > boot-time selection option as userspace depends entirely on this either
> > > being there or not. Why would you have a kernel with both options but
> > > userspace without that?
> >
> > And to follow-up on this, if a distro wanted to support this, why not
> > just provide 2 different kernel images? One with this enabled and one
> > without? It's up to the distro to support such a thing, not the kernel
> > community, right?
>
> That's clearly not an option, they will prefer to keep VT enabled forever
> than adding yet another kernel package.
But that's a distro's choice to make, why are you forcing this onto the
kernel? Either a distro wants to support a userspace with VT enabled,
or not. So then choose the kernel option you wish to have here and away
you go!
> And for distributions that already have kernel and kernel-rt, that
> means maintaining 4 kernels for all combination.
Again, that's a distro choice, you are now forcing us to maintain the
option due to the lack of an agreement in your organization :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 10:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012659-credit-suing-72ce@gregkh>
On 26/01/2026 11:30, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>> on the kernel command line to enable it or not.
>>>>
>>>> This says what is happening, but not why?
>>>>
>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>
>>>> Why are we using a 1990's technology for a new feature? What is this
>>>> going to allow to have happen? Who needs/wants this? Who will use it?
>>>> For what?
>>>
>>> The goal is to ease the transition to disable CONFIG_VT.
>>>
>>> So if this is merged, you can boot without VT on any Linux distribution,
>>> without rebuilding the kernel.
>>
>> But that's a distro-specific thing, the distro should be enabling or
>> disabling the option as it needs, it should not be a user-configurable
>> boot-time selection option as userspace depends entirely on this either
>> being there or not. Why would you have a kernel with both options but
>> userspace without that?
>
> And to follow-up on this, if a distro wanted to support this, why not
> just provide 2 different kernel images? One with this enabled and one
> without? It's up to the distro to support such a thing, not the kernel
> community, right?
That's clearly not an option, they will prefer to keep VT enabled
forever than adding yet another kernel package. And for distributions
that already have kernel and kernel-rt, that means maintaining 4 kernels
for all combination.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 10:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012648-vantage-mummified-2a43@gregkh>
On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>> on the kernel command line to enable it or not.
>>>
>>> This says what is happening, but not why?
>>>
>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>
>>> Why are we using a 1990's technology for a new feature? What is this
>>> going to allow to have happen? Who needs/wants this? Who will use it?
>>> For what?
>>
>> The goal is to ease the transition to disable CONFIG_VT.
>>
>> So if this is merged, you can boot without VT on any Linux distribution,
>> without rebuilding the kernel.
>
> But that's a distro-specific thing, the distro should be enabling or
> disabling the option as it needs, it should not be a user-configurable
> boot-time selection option as userspace depends entirely on this either
> being there or not. Why would you have a kernel with both options but
> userspace without that?
Actually the userspace side works with or without VT, at least with
Fedora, I've my Gnome session in both cases.
>
>> This option will also allow a distribution to disable VT by default, but
>> users that really wants this can enable it on the kernel command line,
>> without rebuilding the kernel.
>
> Why would a user want that? If a user really wants it enabled, why
> would userspace even still work and why would they want to not rebuild
> the kernel?
Rebuilding kernel is not user-friendly, changing a kernel cmdline
parameter is much easier.
>
>> It will also avoid hacky solution in userspace like this:
>> https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
>
> Surely that can't be the only way, why can't userspace just handle this
> "properly" if it wants to?
There is no way for userspace to disable the tty that are running in the
kernel. It can at best ignore them, but for me it's not a proper solution.
>
>>>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>>>> ---
>>>> drivers/tty/Kconfig | 13 +++++++++++++
>>>> drivers/tty/vt/vt.c | 5 +++++
>>>> 2 files changed, 18 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
>>>> index 149f3d53b7608..2b94c2710687a 100644
>>>> --- a/drivers/tty/Kconfig
>>>> +++ b/drivers/tty/Kconfig
>>>> @@ -41,6 +41,19 @@ config VT
>>>> If unsure, say Y, or else you won't be able to do much with your new
>>>> shiny Linux system :-)
>>>> +config VT_ENABLE
>>>> + depends on VT
>>>> + default y
>>>> + bool "enable VT terminal" if EXPERT
>>>
>>> So no one will ever really use this config option?
>>>
>>> And you are doing 2 things in this patch, not just one, unlike what the
>>> changelog said :(
>>
>> I can split that in two if you prefer.
>
> I'm objecting to the patch doing something other than what the changelog
> describes, which as you know is not a good thing.
>
ok, I can fix that in a v2.
>> Adding a module parameter, and adding a Kconfig option, to choose the
>> default for this module parameter.
>
> I really don't like adding new module parameters that we are going to
> have to now support for forever. Why not just rely on the config option
> being there or not as-is? That's why we allowed it to be turned off at
> all, because userspace was going to be moved to not need it anymore.
> Why would we want to support "both" at the same time in the kernel?
>
This parameter is there to ease the transition to VT-less system. So by
maintaining this few lines of code, it will be possible to deprecate the
whole VT in the future.
If a module parameter is not a good solution, I'm open to any solution
that can disable vt from the kernel command line (userspace init runs to
late to disable vt).
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 10:30 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012648-vantage-mummified-2a43@gregkh>
On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > on the kernel command line to enable it or not.
> > >
> > > This says what is happening, but not why?
> > >
> > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > >
> > > Why are we using a 1990's technology for a new feature? What is this
> > > going to allow to have happen? Who needs/wants this? Who will use it?
> > > For what?
> >
> > The goal is to ease the transition to disable CONFIG_VT.
> >
> > So if this is merged, you can boot without VT on any Linux distribution,
> > without rebuilding the kernel.
>
> But that's a distro-specific thing, the distro should be enabling or
> disabling the option as it needs, it should not be a user-configurable
> boot-time selection option as userspace depends entirely on this either
> being there or not. Why would you have a kernel with both options but
> userspace without that?
And to follow-up on this, if a distro wanted to support this, why not
just provide 2 different kernel images? One with this enabled and one
without? It's up to the distro to support such a thing, not the kernel
community, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 10:20 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <48be84fb-bee4-4a22-bde4-0d0c78282f80@redhat.com>
On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > on the kernel command line to enable it or not.
> >
> > This says what is happening, but not why?
> >
> > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> >
> > Why are we using a 1990's technology for a new feature? What is this
> > going to allow to have happen? Who needs/wants this? Who will use it?
> > For what?
>
> The goal is to ease the transition to disable CONFIG_VT.
>
> So if this is merged, you can boot without VT on any Linux distribution,
> without rebuilding the kernel.
But that's a distro-specific thing, the distro should be enabling or
disabling the option as it needs, it should not be a user-configurable
boot-time selection option as userspace depends entirely on this either
being there or not. Why would you have a kernel with both options but
userspace without that?
> This option will also allow a distribution to disable VT by default, but
> users that really wants this can enable it on the kernel command line,
> without rebuilding the kernel.
Why would a user want that? If a user really wants it enabled, why
would userspace even still work and why would they want to not rebuild
the kernel?
> It will also avoid hacky solution in userspace like this:
> https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
Surely that can't be the only way, why can't userspace just handle this
"properly" if it wants to?
> > > Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> > > ---
> > > drivers/tty/Kconfig | 13 +++++++++++++
> > > drivers/tty/vt/vt.c | 5 +++++
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > index 149f3d53b7608..2b94c2710687a 100644
> > > --- a/drivers/tty/Kconfig
> > > +++ b/drivers/tty/Kconfig
> > > @@ -41,6 +41,19 @@ config VT
> > > If unsure, say Y, or else you won't be able to do much with your new
> > > shiny Linux system :-)
> > > +config VT_ENABLE
> > > + depends on VT
> > > + default y
> > > + bool "enable VT terminal" if EXPERT
> >
> > So no one will ever really use this config option?
> >
> > And you are doing 2 things in this patch, not just one, unlike what the
> > changelog said :(
>
> I can split that in two if you prefer.
I'm objecting to the patch doing something other than what the changelog
describes, which as you know is not a good thing.
> Adding a module parameter, and adding a Kconfig option, to choose the
> default for this module parameter.
I really don't like adding new module parameters that we are going to
have to now support for forever. Why not just rely on the config option
being there or not as-is? That's why we allowed it to be turned off at
all, because userspace was going to be moved to not need it anymore.
Why would we want to support "both" at the same time in the kernel?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 9:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <2026012613-cotton-jellied-b67a@gregkh>
On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>> This allows to build the kernel with CONFIG_VT enabled, and choose
>> on the kernel command line to enable it or not.
>
> This says what is happening, but not why?
>
>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>
> Why are we using a 1990's technology for a new feature? What is this
> going to allow to have happen? Who needs/wants this? Who will use it?
> For what?
The goal is to ease the transition to disable CONFIG_VT.
So if this is merged, you can boot without VT on any Linux distribution,
without rebuilding the kernel.
This option will also allow a distribution to disable VT by default, but
users that really wants this can enable it on the kernel command line,
without rebuilding the kernel.
It will also avoid hacky solution in userspace like this:
https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
>
>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>> ---
>> drivers/tty/Kconfig | 13 +++++++++++++
>> drivers/tty/vt/vt.c | 5 +++++
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
>> index 149f3d53b7608..2b94c2710687a 100644
>> --- a/drivers/tty/Kconfig
>> +++ b/drivers/tty/Kconfig
>> @@ -41,6 +41,19 @@ config VT
>> If unsure, say Y, or else you won't be able to do much with your new
>> shiny Linux system :-)
>>
>> +config VT_ENABLE
>> + depends on VT
>> + default y
>> + bool "enable VT terminal" if EXPERT
>
> So no one will ever really use this config option?
>
> And you are doing 2 things in this patch, not just one, unlike what the
> changelog said :(
I can split that in two if you prefer.
Adding a module parameter, and adding a Kconfig option, to choose the
default for this module parameter.
>
> thanks,
>
> greg k-h
>
--
Jocelyn
^ permalink raw reply
* Re: [PATCH] vt: Add enable module parameter
From: Greg Kroah-Hartman @ 2026-01-26 9:33 UTC (permalink / raw)
To: Jocelyn Falempe
Cc: Jiri Slaby, Nicolas Pitre, Calixte Pernot, linux-kernel,
linux-serial
In-Reply-To: <20260126092234.713465-1-jfalempe@redhat.com>
On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> This allows to build the kernel with CONFIG_VT enabled, and choose
> on the kernel command line to enable it or not.
This says what is happening, but not why?
> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
Why are we using a 1990's technology for a new feature? What is this
going to allow to have happen? Who needs/wants this? Who will use it?
For what?
> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> ---
> drivers/tty/Kconfig | 13 +++++++++++++
> drivers/tty/vt/vt.c | 5 +++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index 149f3d53b7608..2b94c2710687a 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -41,6 +41,19 @@ config VT
> If unsure, say Y, or else you won't be able to do much with your new
> shiny Linux system :-)
>
> +config VT_ENABLE
> + depends on VT
> + default y
> + bool "enable VT terminal" if EXPERT
So no one will ever really use this config option?
And you are doing 2 things in this patch, not just one, unlike what the
changelog said :(
thanks,
greg k-h
^ permalink raw reply
* [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe @ 2026-01-26 9:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Nicolas Pitre, Calixte Pernot,
linux-kernel, linux-serial
Cc: Jocelyn Falempe
This allows to build the kernel with CONFIG_VT enabled, and choose
on the kernel command line to enable it or not.
Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
---
drivers/tty/Kconfig | 13 +++++++++++++
drivers/tty/vt/vt.c | 5 +++++
2 files changed, 18 insertions(+)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 149f3d53b7608..2b94c2710687a 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -41,6 +41,19 @@ config VT
If unsure, say Y, or else you won't be able to do much with your new
shiny Linux system :-)
+config VT_ENABLE
+ depends on VT
+ default y
+ bool "enable VT terminal" if EXPERT
+ help
+ This allows to build the kernel with CONFIG_VT, and choose on the
+ kernel command line to enable it or not. If set to y, VT will be
+ enabled by default, but can be disabled with vt.enable=0 on the kernel
+ command line. Otherwise, use vt.enable=1 to enable VT.
+ This should help to transition to VT-less system.
+
+ If unsure, say Y.
+
config CONSOLE_TRANSLATIONS
depends on VT
default y
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..d83613d98f594 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -164,6 +164,8 @@ EXPORT_SYMBOL(global_cursor_default);
static int cur_default = CUR_UNDERLINE;
module_param(cur_default, int, S_IRUGO | S_IWUSR);
+static bool vt_enable = IS_ENABLED(CONFIG_VT_ENABLE) ? true : false;
+module_param_named(enable, vt_enable, bool, S_IRUGO | S_IWUSR);
/*
* ignore_poke: don't unblank the screen when things are typed. This is
@@ -3852,6 +3854,9 @@ ATTRIBUTE_GROUPS(vt_dev);
int __init vty_init(const struct file_operations *console_fops)
{
+ if (!vt_enable)
+ return 0;
+
cdev_init(&vc0_cdev, console_fops);
if (cdev_add(&vc0_cdev, MKDEV(TTY_MAJOR, 0), 1) ||
register_chrdev_region(MKDEV(TTY_MAJOR, 0), 1, "/dev/vc/0") < 0)
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
--
2.52.0
^ permalink raw reply related
* [syzbot] [serial?] KMSAN: uninit-value in gsmld_receive_buf (2)
From: syzbot @ 2026-01-26 5:31 UTC (permalink / raw)
To: gregkh, jirislaby, linux-kernel, linux-serial, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: cf38b2340c0e Merge tag 'soc-fixes-6.19-2' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e05d22580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8bf02b9e495b9fcd
dashboard link: https://syzkaller.appspot.com/bug?extid=60e074cc0d3b54a82cf1
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0bca22500a65/disk-cf38b234.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7d7caf81eafb/vmlinux-cf38b234.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d9e3619531e9/bzImage-cf38b234.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+60e074cc0d3b54a82cf1@syzkaller.appspotmail.com
=====================================================
BUG: KMSAN: uninit-value in gsmld_receive_buf+0x558/0x5d0 drivers/tty/n_gsm.c:3617
gsmld_receive_buf+0x558/0x5d0 drivers/tty/n_gsm.c:3617
tty_ldisc_receive_buf+0x1f7/0x2c0 drivers/tty/tty_buffer.c:391
tty_port_default_receive_buf+0xd7/0x1a0 drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:445 [inline]
flush_to_ldisc+0x43e/0xe40 drivers/tty/tty_buffer.c:495
process_one_work kernel/workqueue.c:3257 [inline]
process_scheduled_works+0xb03/0x1da0 kernel/workqueue.c:3340
worker_thread+0xede/0x1590 kernel/workqueue.c:3421
kthread+0xd5a/0xf00 kernel/kthread.c:463
ret_from_fork+0x207/0x6f0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4960 [inline]
slab_alloc_node mm/slub.c:5263 [inline]
__do_kmalloc_node mm/slub.c:5656 [inline]
__kmalloc_noprof+0xae9/0x1c00 mm/slub.c:5669
kmalloc_noprof include/linux/slab.h:961 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:180 [inline]
__tty_buffer_request_room+0x3d4/0x7a0 drivers/tty/tty_buffer.c:273
__tty_insert_flip_string_flags+0x157/0x6f0 drivers/tty/tty_buffer.c:309
tty_insert_flip_char include/linux/tty_flip.h:77 [inline]
uart_insert_char+0x368/0x930 drivers/tty/serial/serial_core.c:3423
serial8250_read_char+0x1ba/0x670 drivers/tty/serial/8250/8250_port.c:1641
serial8250_rx_chars drivers/tty/serial/8250/8250_port.c:1658 [inline]
serial8250_handle_irq+0x930/0x1110 drivers/tty/serial/8250/8250_port.c:1822
serial8250_default_handle_irq+0x116/0x370 drivers/tty/serial/8250/8250_port.c:1846
serial8250_interrupt+0xcb/0x420 drivers/tty/serial/8250/8250_core.c:86
__handle_irq_event_percpu+0x118/0xec0 kernel/irq/handle.c:211
handle_irq_event_percpu kernel/irq/handle.c:248 [inline]
handle_irq_event+0xe0/0x2a0 kernel/irq/handle.c:265
handle_edge_irq+0x2a9/0xb50 kernel/irq/chip.c:855
generic_handle_irq_desc include/linux/irqdesc.h:172 [inline]
handle_irq arch/x86/kernel/irq.c:255 [inline]
call_irq_handler arch/x86/kernel/irq.c:-1 [inline]
__common_interrupt+0x9d/0x180 arch/x86/kernel/irq.c:326
common_interrupt+0x94/0xb0 arch/x86/kernel/irq.c:319
asm_common_interrupt+0x2b/0x40 arch/x86/include/asm/idtentry.h:688
CPU: 1 UID: 0 PID: 6065 Comm: kworker/u8:16 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Workqueue: events_unbound flush_to_ldisc
=====================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [GIT PULL] Serial driver fixes for 6.19-rc7
From: pr-tracker-bot @ 2026-01-25 18:05 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Stephen Rothwell, Andrew Morton,
linux-kernel, linux-serial
In-Reply-To: <aXY1f0U7rHgwl4bO@kroah.com>
The pull request you sent on Sun, 25 Jan 2026 16:23:43 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-6.19-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/11de40c03cf0f84466f517cc4d58f02ff1ba30be
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [GIT PULL] Serial driver fixes for 6.19-rc7
From: Greg KH @ 2026-01-25 15:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Slaby, Stephen Rothwell, Andrew Morton, linux-kernel,
linux-serial
The following changes since commit f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da:
Linux 6.19-rc3 (2025-12-28 13:24:26 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-6.19-rc7
for you to fetch changes up to 32f37e57583f869140cff445feedeea8a5fea986:
serial: Fix not set tty->port race condition (2026-01-23 17:23:09 +0100)
----------------------------------------------------------------
Serial driver fixes for 6.19-rc7
Here are 3 small serial driver fixes for 6.19-rc7 that resolve some
reported issues. They include:
- tty->port race condition fix for a reported problem
- qcom_geni serial driver fix
- 8250_pci serial driver fix
All of these have been in linux-next with no reported issues
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Krzysztof Kozlowski (1):
serial: Fix not set tty->port race condition
Marnix Rijnart (1):
serial: 8250_pci: Fix broken RS485 for F81504/508/512
Praveen Talari (1):
serial: qcom_geni: Fix BT failure regression on RB2 platform
drivers/tty/serial/8250/8250_pci.c | 2 +-
drivers/tty/serial/qcom_geni_serial.c | 13 ++++++-------
drivers/tty/serial/serial_core.c | 6 ++++++
3 files changed, 13 insertions(+), 8 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox